MaxCD: Efficient multi-flow scheduling and cooperative downloading for improved highway drive-thru Internet systems

Computer Networks 57 (2013) 1805–1820

Contents lists available at SciVerse ScienceDirect

Computer Networks journal homepage: www.elsevier.com/locate/comnet

MaxCD: Efficient multi-flow scheduling and cooperative downloading for improved highway drive-thru Internet systems Shengbo Yang ⇑, Chai Kiat Yeo, Bu Sung Lee Centre for Multimedia and Network Technology, School of Computer Engineering, Nanyang Technological University, Singapore 639798, Singapore

a r t i c l e

i n f o

Article history: Received 14 February 2012 Received in revised form 1 December 2012 Accepted 24 December 2012 Available online 22 March 2013 Keywords: Drive-thru networks Scheduling Cooperative downloading

a b s t r a c t The limitation of existing wireless wide area networks, coupled with the delay tolerant property of many non-realtime applications (e.g. email, file download) enables drive-thru networking, which depends on roadside units (RSUs) to provide vehicular users with intermittent Internet access service. Focusing on the downlink service, MaxCD – a joint multiflow scheduling and cooperative downloading protocol is proposed in this paper with the goal of maximizing the amount of data packets that can be downloaded per drive-thru. Based on the macro-level opportunistic scheduling and node cooperation, the best wireless link(s) (with the highest data rate) between the RSU and vehicular users can always be utilized. On the other hand, the advantage of opportunistic overhearing due to the broadcast nature of wireless medium is also exploited to reduce packet retransmission times, so as to further increase the effective data rate. Since the store-carry-forward delivery manner is adopted for the cooperators to avoid introducing interference to the in-range data communication, a multi-channel collision-free relay mechanism is designed to address the reliable and fast data exchange issue when the vehicular users are outside the service area of the RSU. Our theoretical analysis vindicates the performance gain of the cooperation and extensive simulations demonstrate the efficiency of MaxCD. Ó 2013 Elsevier B.V. All rights reserved.

1. Introduction Driven by the demand of ubiquitous network connectivity and rapidly growing data download service, high speed wireless wide area networks (e.g. 3G, WiMax) have experienced dramatic development in the past few years. However, the relatively high cost has hampered their widespread application, while the effective data rate is still limited. Meanwhile, 802.11 (WiFi) as a cost effective wireless access technology has been widely used in homes and public places, providing people with high speed data service. Though the coverage range of WiFi is limited, recent research works [1–3] have shown the feasibility of so called drive-thru networks which provide vehicular users with Internet access service via roadside units (RSUs). As ⇑ Corresponding author. Tel.: +65 67906579. E-mail address: [email protected] (S. Yang). 1389-1286/$ - see front matter Ó 2013 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.comnet.2012.12.020

further demonstrated in [4,5], WiFi, when integrated with data prefetching, is capable enough to satisfy the requirement of many non-realtime applications, such as email and file downloading. In drive-thru networks, since the contact with the Internet can only happen when the vehicles are within the coverage range of the RSU, how to improve network throughput per drive-thru is a major problem. While most of the existing work aims to improve individual user’s experience by extending the effective coverage range of the RSU using the cooperative vehicles as instant relays (e.g. [6–8]), the contention among vehicular users has not been well addressed. In this paper, we would like to shed light on the network performance from the perspective of the whole system and to investigate the impact of user density. Owing to asymmetry of Internet traffic, we mainly focus on the downlink part of Vehicle-to-Infrastructure (V2I) communications in the following content. From the

1806

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

viewpoint of the RSU, there are several queues destined to different users that are currently within the coverage range. If these data flows are not well scheduled, system performance will be degraded significantly due to the anomaly of 802.111 [9], since the data rates of the wireless links to different users vary dramatically [3]. In this paper, we develop MaxCD (Max-rate based Cooperative Downloading), a joint multi-flow scheduling and cooperative downloading protocol for highway drivethru Internet systems. Being aware of the unique property of vehicular mobility pattern, a macro-level opportunistic scheduling [10] algorithm is used to determine which data queue to serve at a certain time instant, and cooperation among vehicular users is fully exploited to increase network throughput. In particular, we make the following main contributions:  We analyze the system throughput under different scheduling schemes and verify that the Max Rate First (MRF), which can be seen as a kind of macro-level opportunistic scheduling outperforms the other competitive ones. Under MRF, the contention among vehicular users can be alleviated significantly and the RSU is able to transmit data packets using higher modulation rate than those schemes which do not consider the rate diversity of different users.  Cooperation among vehicular users is fully exploited. On one hand, idle vehicles that are nearer to the RSU are employed to download data packets on behalf of the busy user which has data to download. In this way, the RSU can always transmit data using the highest available modulation rate. On the other hand, we also take advantage of the opportunistic overhearing due to the broadcast nature of the wireless medium to further increase the effective data rate.  To address the reliable and fast out-of-range data exchange issue, which is another important component (besides the download portion) of our protocol, we propose a collision free multi-channel relay mechanism, leveraging on the multiple non-overlapping channels of DSRC [11] that is assigned to vehicular communications. Different cooperator and destination pairs can obtain available wireless channels without interfering with each other’s data transmission, in a fully distributed manner, and yet carry out packet relaying concurrently. In this way, the cached data can be delivered to the destination as soon as possible while the packet loss due to the wireless interference is minimized.  Finally, we implement MaxCD in NS-2 [12] and evaluate its performance by extensive simulations. We also compare MaxCD with another cooperation aided protocol V2VR [6] which is designed to improve the performance of drive-thru networks using proxy node’s cooperative

1 In the basic 802.11, each flow has the same priority to access the wireless channel. Since the wireless link qualities between the mobile users and the access point vary, to deliver the same amount of data, different users may occupy different air time, so the user with low data rate (i.e. corresponding to poor wireless link quality) will pull down the overall system performance. Such phenomenon is the so called performance anomaly of 802.11. Interested readers may refer to [9] for more details.

relay. Simulation results show that MaxCD significantly outperforms V2VR under different user densities in terms of throughput per drive-thru. The rest of this paper is organized as follows. We present the system model in Section 2, followed by the discussion of multi-flow scheduling mechanisms and cooperative strategies in Section 3. In Sections 4 and 5, we describe the protocol design of MaxCD, including the download portion and the relay portion, respectively. Performance evaluation through extensive simulations is presented in Section 6. Section 7 reviews the related work and conclusions are given in Section 8. 2. System model Consider a straight highway scenario where RSUs are sparsely deployed. Each RSU gets a certain coverage range in which vehicular users can download data packets. Here we only consider the unidirectional traffic. Assume there are Nl lanes and vehicles traveling in the same lane are at the same constant speed (i.e. regular traffic is assumed by default). Although the assumption may not be applicable to all road scenarios, however, cruising vehicles in the same lane actually maintain constant inter-vehicle distance for a relatively long time. If we ignore the overtaking and suppose such kind of steady state can be maintained longer than the operation time of the data downloading and relaying (similar to the assumption made in [13]), meaningful conclusions can still be drawn. In drive-thru networks, due to the intermittent connection with the RSUs and the delay tolerant property of the concerned applications, we take the throughput per drive-thru as the main performance metric, since larger amount of data that can be downloaded per drive-thru implies the required data can be obtained from fewer number of traversed RSUs, leading to a lower completion time. On the other hand, energy consumption is neglected in our scenario owing to sufficient power supply in vehicles. The transmit power of the wireless interfaces on the RSU and the vehicles are assumed to be the same for simplicity, although the RSU can be more powerful. Since we focus on the download service provided by drive-thru networks, it is assumed that each vehicle entering the coverage range of a RSU has a probability of a (denoted as download probability) that it will download data packets (i.e. have download requirement). The RSU can serve only one user at a time. In the following part, we denote a vehicle with data downloading requirement as a busy vehicle and otherwise as idle vehicle. Saturation mode is assumed by default, i.e. a busy vehicle can always get data to download when it is within the coverage range of the RSU, so as to evaluate the upper bound of the network throughput. According to the measurement result presented in [3], despite channel fluctuation, the highest rate that can be achieved in drive-thru V2I communications is closely related to the distance between the RSU and the vehicle, roughly exhibiting the pattern as illustrated in Fig. 1 (in stochastic manner): the nearer the distance, the higher the data rate that can be achieved. With reference to

1807

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

r j ¼ Rj  ð1  qj;j Þ

ð4Þ

where qj,j is the packet loss rate. Generally, qj,i defines the probability that a packet sent from RSU to the node in Sj (i.e. using the modulation scheme corresponding to Rj) fails to be received by the node in Si. For analytical tractability, we have assumed that the loss rate is identical for the entire road segment and the road segments with the same distance to the RSU will experience the same loss rate (i.e. qj,i = qj,k+1i). 3. Multi-flow scheduling and cooperation It is not uncommon that multiple vehicles in the coverage area of a RSU request data downloading service, leading to multi-flow scheduling issues. Owing to the rate diversity of the different RSU-destination pairs, inadequate scheduling can lead to drastically reduced aggregate throughput.

Fig. 1. Road segmentation model.

Fig. 1, assume there are k road segments denoted as Sj (j = 1, 2, . . . , k), with the RSU located in the central segment Sdk/2e (k is odd) and Vi refers to a vehicle. In our road segmentation model, the data rate is determined by the location of the vehicle, e.g. when a vehicular user is in Sj, it can download data packets with the modulation scheme corresponding to the data rate Rj. The length Lj of Sj is configured according to the measurement result, which will be further described in Section 6.1. Assume the inter-vehicle spacing follows an exponential distribution [14] and the vehicle arrival rate of lane l is kl vehicles/s. Then the corresponding traffic density is given by

ql ¼ kl =v l

ð1Þ

where vl is the vehicular speed in lane l. The probability that there are n busy vehicles in Sj follows the normalized Poisson distribution (Eq. (3) in [16]):

ðaqLj Þn =n! PBj ðnÞ ¼ P B Cj i i¼0 ðaqLj Þ =i!

ð2Þ

PNl where q ¼ l¼1 ql and C Bj denotes the maximum possible number of busy vehicles in Sj due to the vehicle’s physical size limitation. Similarly, the probability that there are n idle vehicles in Sj is given by

ðð1  aÞqLj Þn =n! PIj ðnÞ ¼ P I Cj i i¼0 ðð1  aÞqLj Þ =i!

ð3Þ

where C Ij is the upper bound on the number of idle vehicles in Sj. Different modulation schemes can be used according to the road segment that the vehicular user is located in, so as to control the data sending rate. The effective data rate of a vehicular user located in Sj is given by2 2 Note that here we actually ignore the difference among different lanes for the tractability of analysis. In reality, the lane that is further from the RSU would experience lower average signal strength (and thus lower data rates) and higher presence of obstacles (i.e., vehicles traveling in the other lanes). To solve or alleviate the above mentioned problems, we presume that the RSU should be located on highway signs on top of the road in practical deployment.

3.1. Two naive scheduling schemes In this section, we first present two naive scheduling schemes without considering the specific feature of drive-thru networks. Then a greedy mechanism inspired by opportunistic scheduling [10,15] is presented, in which the flow with the highest modulation rate is always being scheduled. After that, cooperation among vehicular users will be extensively exploited to further boost the network throughput. 3.1.1. Packet based Round Robin (PRR) In PRR, each flow will be polled in order (one data packet per polling time) at the RSU without considering the rate diversity. Without loss of generality, the size of data packet polled from the different flows is assumed to be a constant value D. In the case that there are nj busy vehicles in Sj, the amount of data transmitted by the RSU during the entire P round can be expressed as kj¼1 ðnj  DÞ, and the total transPk mission time is j¼1 ðnj  D=r j Þ. Thus the average overall Pk nj throughput is simply Pk j¼1 . Going through all the cases j¼1

ðnj =r j Þ

pertaining to nj’s distribution, the average overall throughput under PRR can be formulated as follows

Pk Ck C1 k X X Y 1 j¼1 nj TP ¼  PB ðnj Þ Pk 1  Pidle n ¼0 n ¼0 j¼1 ðnj =r j Þ j¼1 j 1

ð5Þ

k

where Pidle is the probability that there is no busy vehicle in the entire RSU’s coverage range:

Pidle ¼

k Y

PBj ð0Þ ¼ e

aq

Pk

L j¼1 j

ð6Þ

j¼1

and Cj denotes the maximum number of vehicles in Sj with probability close to one. It is worth to mention that in Eq. (5), when Pidle increases to one (i.e. corresponding to the case that a tiny portion of the vehicular users have data downloading requirement), the summation also approaches zero in the

1808

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

same order which still renders a finite value for TP. Actually in this case, one busy vehicle, if it exists, takes up almost all the wireless resources, so that the overall throughput equals to that vehicular user’s throughput with high probability. We will further discuss such a special case in Section 3.5. 3.1.2. Time based Round Robin (TRR) In TRR, the operation of RSU is divided into time slots and each flow is assigned a fixed occupancy time, as per the scheme described in [16]. In this way, less air time will be occupied by the poor-rate flows, leading to higher system throughput. Assume the time assigned to each flow is d, then for the whole round, the amount of data transPk mitted by the RSU is j¼1 ðnj r j  dÞ. As the duration of a Pk round-robin round is j¼1 ðnj  dÞ, the average overall throughput under the condition that there are nj busy vehiPk nj r j cles in Sj is given by Pj¼1 . Consider nj’s distribution, the k n j¼1 j

average overall throughput under TRR can thus be formulated as follows

TT ¼

Pk Ck C1 k X X Y 1 j¼1 nj r j  PBj ðnj Þ Pk 1  Pidle n ¼0 n ¼0 n j¼1 j j¼1 1

ð7Þ

k

3.2. Max-Rate First (MRF) In MRF, the flow whose destination is nearest to the RSU (i.e. the data rate of this flow is the highest according to our system model) will be assigned the right to transfer.3 Since each vehicle will enter the segment with the highest rate, this scheme can achieve significant performance gain by alleviating the negative effect of the contention from the low-rate flows, while every busy vehicle can still get the downloading chance within a specific time period when he is near to the RSU. The average overall throughput is given by

TM ¼

Ck C1 k X Y X 1  maxfrj g PBj ðnj Þ 1  Pidle n ¼0 n ¼0 j¼1 1

k

( ) bk=2c kj o X X n B 1 B B r j P Nj þ N kþ1j > 0  P Ni ¼ 0 ¼ 1  Pidle j¼1 i¼jþ1 n o ð8Þ þ r dk=2e P NBdk=2e > 0 where N Bj denotes the random variable representing the number of busy vehicles in Sj. The calculation of TM follows the rule that only if there is no busy vehicle in the segments with higher modulation rate then will the user in the segment with lower modulation rate perform data transfer. Comparing with Eqs. (5) and (7), it is not difficult to obtain the following inequalities:

TP 6 TT 6 TM

ð9Þ

3 In reality, to alleviate the negative effect of location inaccuracy and to achieve higher fairness, if two busy vehicles are of comparable closest proximity to the RSU, both data flows will be scheduled on the basis of PRR.

Among the three scheduling schemes above, we can see that MRF is the best from the perspective of the overall throughput. However, a potential problem is that not all passing vehicles have data to download. In order to fully utilize the link with the highest available data rate, Cooperation-aided Max-Rate First (CMRF) is proposed in the following subsection. 3.3. Cooperation-aided Max-Rate First (CMRF) In CMRF, when the RSU selects a data queue destined to Vi (located in Sj) whose data rate is the highest among all the receivers, it will further check whether there is any Vi’s neighboring node which is traveling in the same lane with an even higher data rate.4 If yes, the data packets will be forwarded to that node and later relayed to the real destination after the involved vehicles move out. We denote such cooperation as proactive cooperation. Neighboring here means the distance between the cooperator and the busy vehicle should not exceed a certain threshold, which is defined as the cooperation range, so as to ensure that the data link between them would not be too poor. In the ideal case (i.e. all the vehicles in the same lane move at the same constant speed and all the data can be finally relayed to the destination vehicles), the average overall throughput under CMRF, TC, can be written as follows

( ) bk=2c kj n o X X 1 r Pj P NBj þ N Bkþ1j > 0  P NBi ¼ 0 1  Pidle j¼1 i¼jþ1 n o þrdk=2e P NBdk=2e > 0 ð10Þ

TC ¼

where rPj is the effective data rate when proactive cooperation is involved. Comparing Eq. (10) with Eq. (8), we can see that as long as not all vehicles are busy, r Pj is expected to be larger than rj and thus TC P TM. Note that Eq. (10) is obtained under the assumption that all the data packets cached by the cooperators will be successfully relayed to the real destination. Though the network topology will remain unchanged due to the assumption of the constant speed, inadequate relay operation will also cause packet loss. The design of the relay portion will be detailed in Section 5. In this section, we just assume the existence of ideal packet relaying so as to obtain the maximum amount of throughput improvement which can be derived from vehicular cooperation. 3.4. Reactive cooperation The basic idea of reactive cooperation is that vehicles in the neighborhood (i.e. within the cooperation range) of the current busy user can listen to the wireless channel and opportunistically overhear data packets in the air. In vehicular networks, the error prone wireless channel will lead to several retransmissions of a packet before it is eventually delivered. Actually due to the broadcast nature of the wireless medium and link spatial diversity, a packet which fails 4 It implicitly means that such neighboring node, if exists, must be an idle vehicle.

1809

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

3.5. Numerical verification To preliminarily evaluate the effect of scheduling and cooperation, we conduct some numerical experiments. The protocols to be compared include PRR, TRR, MRF and CMRF. Single lane traffic scenario is used and the inter-arrival time of vehicles obeys exponential distribution with average of 5 s. The node speed is set to 20 m/s and a vehicular user is determined with a certain probability that it has data to download. 802.11p is employed with four rates: 3, 6, 12 and 24 Mbps. A time-driven simulator written in C++ is used in the experiments. We maintain the states of each node, including its location and data related variables. At each snapshot, according to the positions of the nodes, data flows are scheduled and the amount of data that is downloaded by each node is calculated. The calculation of the data rate is based on Eq. (4) without taking much underling PHY/MAC layer detail into consideration as here we only focus on the scheduling model validation. More complex and realistic performance evaluation will be presented and discussed in Section 6. The numerical results are shown in Fig. 2. In Fig. 2, we plot the simulated overall throughput with points and theoretical results with curves according to Eqs. (5), (7), (8), and (10). It can be observed that when more vehicular users ask for data download service, the overall throughput of PRR decreases indicating the impact of per5 Note that Vi here refers to a busy vehicle, not in-range receiver which may be the busy vehicle’s proactive cooperator.

18 16 Overall throughput (Mbps)

to be received by the destination may be successfully overheard by nearby neighbors. If the neighbor can cooperatively reply to the RSU with ACK, no more retransmission is necessary and the RSU can continue to transmit the subsequent packets. As a result, more fresh data packets can be downloaded from the perspective of the whole group. We also like to exploit such cooperation, which is inspired by opportunistic routing in wireless mesh networks [17,18] as well as opportunistic retransmission [19] and relaying [20], to reduce retransmissions, so as to improve network throughput. Similar to the proactive cooperation, a vehicle Vj may be Vi’s reactive cooperator if: (1) it is idle; (2) it is traveling in the same lane as Vi; (3) the distance between Vj and Vi does not exceed the cooperation range; (4) it gets a comparable if not better data link to the RSU compared to Vi (it is either nearer to the RSU than Vi or further but within a certain threshold thus leading to comparable data link).5 In our implementation, to control overhead we set the maximum number of reactive cooperators to two. Thus if there are more than two reactive cooperator candidates which satisfy the above constraints, those two with better data rates (i.e. nearer to the RSU) will be selected. Reactive cooperation can actually be used in all the above scheduling mechanisms to improve throughput. Our proposed scheme (MaxCD) is none other than CMRF incorporated with reactive cooperation. It is worthwhile to highlight that in MaxCD when proactive cooperator is also available, Vi itself also contends for the reactive cooperator position.

14 PRR TRR MRF CMRF

12 10 8 6 4 2 0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

Download probability Fig. 2. Theoretical overall throughput.

formance anomaly. TRR keeps the system throughput almost constant due to its time slotted access policy, while under MRF and CMRF, the overall throughput increases. CMRF performs best due to the utilization of cooperation among vehicular users. However, as the download probability increases, the performance gap between CMRF and MRF gradually disappears, since only idle vehicle will participate in proactive cooperation as defined. It can also be seen that the theoretical analysis tracks the performance quite well. Recall the note mentioned at the end of Section 3.1.1 that when the download probability is close to 0 (0.01 in our numerical experiment), bandwidth contention among different busy vehicles within the RSU’s service range vanishes, leading to the same overall throughput of PRR, TRR and MRF, while CMRF fully enjoys the benefit of cooperation and achieves much higher performance. 4. Protocol design: download part The protocol design of MaxCD can be divided into two parts, the download part and the relay part. The former deals mainly with the multi-flow scheduling issue and cooperative downloading in which the RSU plays the key role, while the later addresses the out-of-range relay. We first introduce the download part in this section and the relay part will be described in the next section. In our network scenario, we have a basic assumption that the required data is already cached at the RSU, as mentioned in Section 2. Such prefetching can be done using wireless wide area network as coordination channel [4], or by some kind of prediction [5]. On the other hand, since our focus is on the throughput per drive-thru, if a vehicular user is confirmed to be busy when it enters the coverage range of the RSU, it always has data to download in this drive-thru period, i.e. the data queue for this user is infinite. In addition, each vehicle including the RSU is assumed to be equipped with two wireless interfaces. One interface (denoted as control interface) is fixed on the control channel while the other one (denoted as data interface) can

1810

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

operate dynamically on the remaining six service channels of DSRC, similar to the assumption made in some related work (e.g. [21,22]). The main advantage of such deployment is that control packets and more importantly safety messages which are scheduled to be transmitted on the control channel will not be blocked by the potential heavy data traffic since two independent interfaces are used and they operate on non-overlapping channels. In this paper, as we only consider commercial data downloading service, the control interface is thus specifically used to exchange control packets. 4.1. Cross-layer design framework at RSU In MaxCD, the RSU periodically broadcasts Beacon packet which contains its location information to advertise the existence of data downloading service. Whenever a vehicle Vi receives the Beacon, it will reply the RSU with a Register message which contains its own location information (xi) and speed (vi). The RSU will update a client list as soon as it receives a reply. The corresponding item in the client list will either be created for a new vehicular user, or refreshed with the new value of xi and vi, as well as the registration time ti. The moving direction can also be obtained by comparing with the last record. In this way, the distance between Vi and the RSU at time t can be estimated in a finegrained manner. As illustrated in Fig. 3, we have designed a cross-layer framework for the RSU. The client list of vehicular users is maintained at the IP (routing) layer. When a busy vehicle comes in, the corresponding data flow will be added at the application layer. Since we would like to do throughput measurement, the sending rate of each data flow is set high enough to saturate the wireless link. In the IFq (interface queue, between LL and MAC), different data queues are maintained for different flows, in addition to the queue for control messages. Based on the client list, the data queue with the highest rate will be activated (different scheduling mechanisms can also be implemented). A spe-

cific timer for each vehicular user is maintained to indicate if the user has already moved out. If a particular timer expires, the corresponding vehicular user will be removed from the client list and the related data flow and data queue will also be cleared. Here two cooperation configurations are involved corresponding to the proactive and reactive modes, respectively. Firstly at the routing layer, it will check whether a data packet destined for vehicular user Vi can be forwarded to a cooperator Vj which is nearer to the RSU, denoted as CoopConfig1 in the figure. When the data packet reaches the MAC layer, CoopConfig2 will be executed to see whether reactive cooperators are available. If yes, the candidate list (described in the next subsection) will be added to the packet header, again based on the information maintained in the client list. 4.2. Reactive cooperation Reactive cooperation is proposed to reduce the retransmission time of a data packet so as to improve network throughput. In the basic access mode of 802.11 DCF, if there is only one data flow and the channel condition is perfect and interference free, the average time needed to successfully deliver a data packet Ts can be expressed as

1 T s ¼ DIFS þ CW min  DT þ DATA þ SIFS þ ACK 2

ð11Þ

where DT is the backoff slot time. However, when transmission error occurs and the data packet is delivered after a retransmission, the time increases to Tr:

1 T r ¼ T s þ AckTimeout þ DIFS þ ð2CW min þ 1Þ  DT 2 þ DATA

ð12Þ

It can be seen that retransmission introduces on average doubled backoff time besides wasting the time period originally prepared for the next data frame.

Fig. 3. Cross-layer design framework at RSU.

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

1811

Fig. 4. Reactive cooperation: if Veh1 succeeds in overhearing DATA (j) it will cooperatively reply to the RSU with ACK, then new data packet DATA (j + 1) can be scheduled with contention window size CWmin.

If reactive cooperation is involved, the situation will change. In the operation of reactive mode, a list of candidates will be added to the packet header (in our work, the number of candidates is set to two). As illustrated in Fig. 4, when the receiver fails to receive the packet and no ACK is overheard in the waiting period, candidates that have received the data will reply with ACK in a predefined order. In this way, the packet transmission time can be significantly decreased. In the case shown in Fig. 4, the average transmission time is reduced to

T c ¼ T s þ ðn  1Þ  SIFS þ ACK

ð13Þ

where n is the priority of the candidates. For 1st-priority candidate (Veh1), no additional waiting time is introduced before ACK, while a SIFS period is necessary for the 2ndpriority candidate (Veh2). The ACK from Veh1 has two functions: acknowledging the RSU for the reception of the data frame and suppressing Veh2’s duplication. It should be noted that at the RSU, only the successful reception of the whole ACK frame will indicate the successful reception of the Data frame, while for Veh1 and Veh2 (the cooperators), carrier sense during the waiting period will be regarded as suppression (ACK) so as to reduce possible duplication. Since all the other nodes within the carrier sense range will keep listening for at least a DIFS period (DIFS > SIFS) after their NAV timer times out (as illustrated in Fig. 4) according to 802.11 DCF, the air time of Veh1 and Veh2’s transmission of ACK is actually reserved, making our reactive cooperation design compatible with the 802.11 MAC. 5. Protocol design: relay part For a vehicular user, if it receives a data packet for another vehicle, it will temporarily cache the packet in a local queue instead of relaying immediately to avoid introducing interference to ongoing data flows. Similar to the download part as done at the RSU, a vehicular user also maintains different queues for different destinations. However, the queues are managed at the IP (routing) layer and only one general data queue exists at the IFq. A cooperator will not conduct packet relaying for two different destinations simultaneously. To avoid packet loss due to IFq

overflow, an adaptive callback scheme is implemented: the ongoing queue in the IP layer will only be scheduled when the IFq length is less than a certain threshold. 5.1. Node state management In the operation of MaxCD, each node (inclusive of the vehicular users and the RSU) maintains state information which can be Idle, Sending, Receiving, Wait To Send, Ready To Send and Wait To Receive. The former three states indicate the working status of the data interface, while the later ones are used in the channel assignment procedure before packet relaying. Note that the state of the RSU is always Sending and the state of the busy users together with the involved cooperators within the coverage range of the RSU is Receiving. For Sending and Receiving, an additional variable named as data_channel_index is also maintained to indicate which channel the data interface is currently working on.6 A cooperative node can only initiate data relay to a destination when the following three conditions are satisfied: (1) the cooperator itself is Idle; (2) the destination is also Idle; (3) there are available data channels that have not been occupied. We will next present the channel assignment mechanism in detail. 5.2. Distributed channel assignment As illustrated in Fig. 5, when a vehicle Vs moves out of the coverage range of the RSU, it will check whether some data packets have been cached in the relay queues (denoted as checkRelayQueue ( ) in the figure). If yes, it will change its state from Idle to Wait To Send. A channel probe packet (denoted as ProbeS since it is issued by the sender) will be broadcast using the control interface (denoted as sendProbeS ( )) and a probe listening timer (PLtimer for short) will also be set. All neighboring nodes whose states are Sending or Receiving will reply with their respective values of the data_channel_index. Then Vs is able to know which channels have already been occupied. It will keep listening to other nodes’ replies until the PLtimer expires. 6 The data channel employed for the RSU’s data transmission is fixed and can be disseminated to the vehicular users via the Beacon message.

1812

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

Fig. 5. Node state transition diagram.

Then it will send a Request message to the destination Vd and its state will be changed to Ready To Send at the same time. On receipt of the Request, Vd will also initiate a channel probe procedure as per Vs. However, unlike ProbeS, the probe issued by the receiver (ProbeR for short) contains a free channel list which is extracted from the Request message. Only the nodes that are currently working on the channels within the list will reply, so as to reduce control overhead. After that, Vd further weeds out the channels that have already been employed, and reply Vs with a Reply message which contains the selected channel. Note that if there are multiple available channels, Vd just randomly chooses one of them to use. On the other hand, we also let the Request message carry Vs’s location information. Therefore, Vd can determine the suitable modulation scheme according to the distance between them and such information is also piggybacked in the Reply message. Vs will start to send data packets as soon as the Reply message gets received. When the relay queue to Vd is completed, Vs will send out an End message and return to the Idle state, while Vd will also change its state from Receiving to Idle on the receipt of the End message. 5.3. Backoff and network-layer NAV The procedure described in Section 5.2 is actually the most successful case. In practice several events may stop the normal operation and the involved data relay has to be suspended and undergo a backoff period. There are three possible cases that can make the node(s) fall back to the Idle state instead of starting the packet transmission: (1) The destination node Vd is currently busy with receiving from another node. Since each node only gets one data interface, Vs has to backoff until Vd completes the ongoing task and returns to the Idle state. Such kind of backoff is denoted as BO_DST_BUSY. Here a coarse-grained NAV is introduced to facilitate the configuration of the backoff timer. Each node which is sending or receiving data packets maintains a local estimation of the remaining

time of the ongoing data flow (using Eq. (11)7), defined as Network-layer NAV (NNAV for short). The name is actually borrowed from DCF of 802.11. However here, NNAV is used to estimate the remaining channel occupation time and the accuracy is much lower than that used in 802.11. In fact the value of NNAV is always shorter than the actual time to complete the data transmission so as to prevent wastage of the wireless resource. In our protocol design, a random backoff time denoted as BACKOFF_TIME which is uniformly distributed in [1s, 2s] is used as the minimum value of NNAV to prevent high-frequency channel probe from being initiated by Vs. Thus when Vd, which is busy, detects the relay procedure initiated by Vs, a Hold message that contains the value of NNAV maintained by Vd will be sent to Vs, and Vs will not disturb Vd in the next backoff period. Note that the Hold message can be sent as soon as Vd hears the ProbeS issued by Vs. If the probe is missed by Vd (due to wireless fading or interference, as the probe is transmitted using unreliable broadcast), the Hold message can be sent when the Request reaches Vd. (2) All available data channels have already been occupied. To avoid contending with the ongoing data flows, backoff defined as BO_CHAN_BUSY has to be executed. In our protocol design, when a node replies with the channel probe message, it also reports its NNAV besides the data channel that is being used. Thus the initiator of the channel probing is able to know the time needed for the corresponding channel to become free again. At the end of the channel probing, the minimum value of these NNAVs denoted as MIN_WAIT_TIME will be recorded. If the situation in which all channels are busy is detected by Vs, it will change its state back to Idle and begin to backoff directly with a period of MIN_WAIT_TIME. If the situation occurs during Vd’s probe period, Vd will also send a Hold message

7 Note that for the vehicles within the coverage range of the RSU, NNAV is set as the remaining time before moving out.

1813

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

to Vs besides returning to the Idle state. The NNAV value contained in the message is just set as MIN_WAIT_TIME to trigger Vs’s backoff. (3) Concurrent initiation of the relay procedure. In this case, more than one cooperator initiates the relay procedure and have started with the channel probing. Thus we have to decide which one could continue while the rest has to be suspended. We first give different priorities to the three states related to the channel assignment. When a ProbeS is received, the node in state Ready To Send or Wait To Receive will directly reply with a Hold message to trigger the BO_CHAN_BUSY at the sender. However, if the node is in state Wait To Send, it implies that the progress of the two relay procedures are almost the same. In this case, the node which leaves the coverage range of the RSU earlier will continue with its packet relaying, i.e. a Hold message will be issued to stop the sender if the receiver finds that it moves ahead. Otherwise the receiver will execute BO_CHAN_BUSY to avoid introducing potential collision in the following data transmission. When a ProbeR is received, the node in state Wait To Send will be stopped automatically while the node in state Ready To Send or Wait To Receive will do likewise according to the leaving order from the RSU. The dashed arrows shown in Fig. 5 represent the state transition due to the receipt of the Hold message, caused by the three possible events discussed above. It is worth mentioning that in some cases, the nodes involved in data relaying may not obtain the full knowledge of the channel utilization due to wireless fading and interference (in the control channel), and the concurrent initiation of data relaying may not always be detected. However, recall the random selection of the available free channels mentioned in Section 5.2, the collision rate between two data flows is actually quite low. Hence the ‘‘collision free’’ status mentioned earlier should be understood in the statistical sense, i.e. in most cases, it is collision free but some exceptions may still exist. In the event that collision occurs, as the number of concurrent data flows that may interfere with each other would not be large, it can still be resolved by the 802.11 MAC.

can be scheduled. A queue can be scheduled when the following two conditions are satisfied: (1) the node state is Idle; (2) no other queue is pending due to BO_CHAN_BUSY. Note that even if there is a relay queue that is pending to be relayed (i.e. backoff has been executed), another relay queue (destined to a different node) will still be tried in the case that the backoff is due to DST_BUSY, so as to fully utilize the wireless resource. 6. Performance evaluation To evaluate the performance of MaxCD, we conduct extensive simulations in NS-2 [12]. IEEE 802.11p (RTS/ CTS disabled) with four modulation schemes (BPSK, QPSK, 16QAM, 64QAM) is simulated using the Nakagami propagation model [23]. For simplicity only four corresponding data rates are used in our simulation: 3 Mbps, 6 Mbps, 12 Mbps and 24 Mbps. 6.1. Throughput measurement and road segmentation We first measure network throughput at different landmarks with varying distance to the RSU. The RSU is allocated at the center of a straight line and a mobile node is deployed at different points along the line with distance interval of 10 m. The RSU sends unicast data packets to the mobile node at saturation rate using different modulation schemes and the results are shown in Fig. 6. It can be seen that different road segments prefer different modulation schemes. Our link quality measurement (not presented here due to page limitation) has shown that when the modulation scheme with higher rate is used, packet delivery ratio drops more significantly as the distance between the mobile node and the RSU increases. In other words, the higher the data rate of a modulation scheme, the narrower is the coverage range in which the packet delivery ratio can be maintained. When the distance to the AP exceeds a certain threshold, packet delivery ratio is so low that even if the sending rate of a modulation scheme is higher than another one, the effective throughput is actually lower. That is why QAM16 achieves higher

14

In Fig. 5, besides the solid arrows which represent the uninterrupted process and the dashed arrows corresponding to the backoff procedure triggered by the Hold message, there are still two dotted arrows which make the node transit from Ready To Send or Receiving to Idle states, which are caused by the timeouts of the ready to send timer (RTStimer for short) and the receiving timer (RECtimer for short), respectively. Such kind of timer-assisted state monitoring is designed to ensure that a vehicle will not be blocked in the Ready To Send state or the Receiving state, due to the transmission failure of the Request, Reply or End messages. On the other hand, the relay queues in each cooperator will be periodically checked to see whether certain queue

Unicast throughput (Mbps)

5.4. Timer-assisted state monitoring and relay queue check

BPSK QPSK QAM16 QAM64

12 10 8 6 4 2 0 -600

-400

-200 0 200 Distance to AP (m)

Fig. 6. Throughput measurement.

400

600

1814

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

Fig. 7. Simulation scenario.

the average amount of data downloaded by a vehicular user when she/he passes by the RSU. Three other schemes are simulated besides MaxCD for comparison. Two of them are PRR and MRF that have been mentioned in Section 3, and the third is V2VR [6], another cooperation aided protocol that is designed to improve the performance of drivethru networks. The original version of V2VR is actually used for uplink. In our simulation, we implement a revised V2VR, but with the same concept as that of the original. In the operation of V2VR, each vehicle is equipped with two interfaces, one is working in infrastructure mode for the communication with the RSU and the other is working in ad hoc mode for the inter-vehicle communication. A

throughput than QAM64 when the distance to the RSU is larger than 50 m, and so on. Through the above measurement, we obtain the valuable knowledge of the optimum modulation scheme that should be used for a particular road segment. Such kind of measurement can also be done in real deployment, similar to the link test conducted before the operation of ExOR [17] deployed on Roofnet. 6.2. Throughput per drive-thru

20 PRR V2VR MRF MaxCD

18 16 14 12 10 8 6 4 2 0 0

Average data downloaded per user (MB)

Average data downloaded per user (MB)

Average data downloaded per user (MB)

We then evaluate the main performance metric concerned, i.e. throughput per drive-thru, which is defined as

0.2

0.4 0.6 Download probability

0.8

1

20 PRR V2VR MRF MaxCD

18 16 14 12 10 8 6 4 2 0 0

12 PRR V2VR MRF MaxCD

10 8 6 4 2 0 0

0.2

0.4 0.6 Download probability

0.8

1

Fig. 8. Throughput per drive-thru.

0.2

0.4 0.6 Download probability

0.8

1

1815

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

We simulate the four protocols under different traffic densities (k) and download probabilities (a). The results are shown in Fig. 8, and the main observations are listed as follows: Firstly, the performance of the four protocols ranges from good to poor in the order: MaxCD > MRF > V2VR > PRR, and the order is regardless of the settings of the parameters, testifying to the high efficiency of MaxCD. Secondly, when more users ask for data downloading service, each user will get less of what can be downloaded per drive-thru, which is expected since the total amount of data is limited by the link capacity of the RSU. However, we can see from the figures that as a increases, the performance of PRR and V2VR degrades very significantly and even approaches zero due to the anomaly of 802.11, while MaxCD and MRF can guarantee that each user can still get relatively high amount of data even when all nodes are busy vehicles owing to the road segmentation based scheduling policy. The improvement is more remarkable when the traffic density is high. On the other hand, the performance gap between MaxCD and MRF decreases gradually when a increases due to the lack of cooperators.

busy vehicle cooperates with two idle vehicles as proxies, one ahead and one behind, if they exist. When the link quality between the busy vehicle and the RSU is good enough (i.e. the distance between them is less than a certain threshold), the RSU will send data packets to the busy vehicle directly. Otherwise, the data will be redirected to the proxy node and the latter will relay the data to the destination using another interface immediately. The simulation scenario used in this section is shown in Fig. 7. A three-lane unidirectional straight highway is involved with the lane width configured as 5 m. A RSU is deployed at a location 1 km away from the left end of the simulation area, with the service range being 400 m. 200 vehicles enter the left end of each lane following Poisson process with parameter k vehicles per second, and keep moving towards the right end until they reach the simulation boundary. It is assumed that vehicles traveling in the same lane are of the same constant speed and the speed for the three lanes are set at 30 m/s, 25 m/s and 20 m/s, respectively. The length of the highway is 8 km, which is long enough to ensure that all data relaying can be completed before the related vehicles reach the right end.

22 PRR V2VR MRF MaxCD

35 30

Amount of data downloaded (MB)

Amount of data downloaded (MB)

40

25 20 15 10 5 0

PRR V2VR MRF MaxCD

20 18 16 14 12 10 8 6 4 2 0

0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

Percentile of busy vehicles (descending order)

0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Percentile of busy vehicles (descending order)

Amount of data downloaded (MB)

14 PRR V2VR MRF MaxCD

12 10 8 6 4 2 0 0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Percentile of busy vehicles (descending order)

1

Fig. 9. Individual performance gain vs. fairness.

1

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

For V2VR, though two data interfaces are used to achieve the concurrent downloading and relaying, the performance improvement compared with PRR is not so evident. The main reason is that such cooperation does not reduce the number of data flows contending for the wireless resource. The only benefit is that for those busy vehicles that are relatively far from the RSU, some idle vehicles with higher data rate may help in the download, and therefore the performance anomaly of 802.11 can be alleviated from the perspective of the RSU. On the other hand, the end to end capacity is actually constricted by the poorer of the two wireless links, one is between the RSU and the cooperator, and the other one is between the cooperator and the destination, due to the instant relaying. Whereas in MaxCD, we divide the download and relay into two parts. In this way, the data packets downloaded in the RSU’s service range can be maximized and only one data interface is necessary. 6.3. Individual performance gain vs. fairness Fig. 9 shows the amount of data downloaded by each vehicle, sorted in descending order, under various download probabilities with vehicle arrival rate k = 0.2 vehicles/s. It can be seen that with MaxCD, the enhancement of the entire system is not at the cost of the individual user’s performance degradation. All users’ performance is improved, though some of them benefit more due to the different vehicular traffic patterns. The performance ranking of the four protocols is consistent with that shown in Fig. 8b, whereas an interesting observation is that the MRF curve shifts from the V2VR curve to the MaxCD curve when the download probability increases. This is because when the download probability is low (see Fig. 9a), in most cases there is only a small number of busy vehicles in the RSU’s service area, the performance of MRF is not much different from that of V2VR (and PRR), while MaxCD can fully enjoy the benefit of idle vehicles’ cooperation. When the density of busy vehicles increases (see Fig. 9b and c), the performance anomaly together with the lack of available cooperators will push the MRF curve away from the V2VR curve to the MaxCD curve. Pertaining to fairness, as observed in Fig. 9, MaxCD has a huge data downloaded differential between the good and poor users compared to the others. However, it should be noted that the MaxCD curves are significantly higher than V2VR and PRR, and they also outperform MRF under both light and heavy busy vehicular traffic due to MaxCD’s unique ability to avoid contention and to exploit cooperation. One may argue that MaxCD is thus not as fair as the others from the users’ perspective. However the truth is that MaxCD is able to bring about great improvement to most users with the worst case users not being worse off than the other protocols. In other words, MaxCD actually benefits every user, and the long-term averaging effect will further reinforce the significant improvement and fairness to individual users. 6.4. Proactive cooperation vs. reactive cooperation In MaxCD, two cooperation modes are introduced to utilize idle neighboring vehicles’ wireless bandwidth. To

Data downloaded per drive-thru (MB)

1816

18 Direct transmit Proactive relay Reactive relay

16 14 12 10 8 6 4 2 0 0.1

0.15

0.2

0.3

Download probability Fig. 10. Performance gain of the two cooperation modes, k = 0.2 vehicles/ s.

reveal the impact of the two modes on the overall performance, we further look into the respective amounts of data directly downloaded from the RSU and boosted by the two cooperation modes, as shown in Fig. 10. Here we only plot the case for k = 0.2 vehicles/s for illustration, as the results for the other two traffic densities are similar. It can be observed that generally the proactive cooperation dominates the performance gain, though reactive mode also brings benefit. This is because the performance gain of reactive cooperation comes from the increased diversity due to opportunistic overhearing, and such improvement is particularly evident when the wireless links of the source–destination and source–cooperators are with comparable qualities. In our protocol design, due to the max-rate first scheduling, the quality of the wireless link between the RSU and the busy vehicle is usually much better than the wireless links between the RSU and the reactive cooperators, resulting in the non-apparent improvement. However, it should be noted that in the denser-traffic cases (e.g. k = 0.5), as the difference in link qualities decreases, the percentage of improvement brought about by proactive cooperation shrinks while the contribution of reactive cooperation increases.

6.5. Data relay ratio From the simulation results presented in the previous subsections, it is clear that cooperators with better wireless links help to download data packets, leading to the increase in total downloading volume. When they move out of the RSU’s coverage range, this part of the data (which is downloaded by the cooperators) needs to be relayed to the real destination, so as to achieve the performance gain. For the relay part, there are basically two issues: (1) How much of these data packets can be delivered to the real destination (from its cooperators); (2) How fast can the relay procedure be completed. In the following part, we will focus on the performance evaluation of the relay scheme. We first consider the data relay ratio, which is defined as the percentage of data packets that are finally delivered

1817

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

1

Data relay ratio

0.99

Average packet caching time (sec)

64

MaxCD* MaxCD(1)

0.98 0.97 0.96 0.95

60

MaxCD* MaxCD(1) MaxCD(2) MaxCD(6)

56 52 48 44 40 36 32 28 24 20

0.94 0

0.2

0.4 0.6 Download probability

0.8

1

Fig. 11. Data relay ratio, k = 0.5 vehicles/s.

to the destination (from its cooperators) divided by the amount of data downloaded by the cooperators. To see the effect of the collision free channel reservation in our protocol, we take a modified version of MaxCD, denoted as MaxCD as comparison. In MaxCD, only the DST_BUSY is handled, without considering the potential collision caused by wireless interference due to concurrent transmission in the same data channel. Therefore only one data channel is used in MaxCD. For the sake of fairness, the version of MaxCD to be compared with also employs one data channel which is denoted as MaxCD (1), while the available data channels that can be used in MaxCD actually can be as many as six. The simulation result for the case k = 0.5 vehicles/s is illustrated in Fig. 11. From the figure we can see that MaxCD (1) achieves near 100% data relay ratio while a certain number of data packets fail to be delivered in MaxCD due to wireless interference. When the download probability a is 0.5, MaxCD performs worst, indicating that the network congestion is the most severe. As a increases further from 0.5 to 0.9, the data relay ratio rises instead of dropping further. This phenomenon can be explained as follows. When the download probability increases, although the distance between busy vehicles becomes shorter, the network traffic load to each busy vehicle is also decreased due to the reduced service time, and therefore there exists some kind of extreme point at which the impact of wireless interference is the most critical. The results for the cases corresponding to the other two vehicle arrival rates (i.e. k = 0.1, 0.2) are similar, with the extreme points shifting right as the vehicular density becomes sparser. It is worth mentioning that, in MaxCD (1) there is still a small part of data packets being lost either due to the failure in channel coordination caused by the loss of control packets or inter-lane interference caused by the speed differentiation. However, when we increase the number of available data channels, such kind of packet loss can be further decreased owing to the random selection of free channels mentioned in Section 5.2.

0

0.2

0.4

0.6

0.8

1

Download probability Fig. 12. Average packet caching time, k = 0.2 vehicles/s.

6.6. Packet caching time vs. number of data channels In last subsection, we make sure that reliable data relay, which is the cornerstone of the performance improvement brought about by cooperative downloading, can be achieved using our channel reservation scheme. Now another concern is how fast the data relay procedure can be completed. We thus measure the caching time of data packets. Here the packet caching time (denoted as Tcache) is defined as the time period a data packet stays in a cooperator’s relay queue, i.e. from the moment it is downloaded, until being delivered to the destination. The simulation result is shown in Fig. 12. It can be seen from the figure that though channel reservation increases robustness, it also introduces a long period of waiting time. However, when multi-channel utilization is involved, the situation will change. The use of only one more data channel makes MaxCD perform better than MaxCD. As the number of available data channels further increases, the packet caching time will be reduced further, but the improvement shrinks. The reason for such difference in the performance gain due to the increased number of data channels can be explained as follows. Since a cooperator will not initiate data relaying before moving out of the RSU’s service area, Tcache thus consists of two parts, Tc and Tw, where Tc is the inrange carrying time and Tw is the out-of-range waiting time. It is obvious that the multi-channel utilization only works for the reduction in Tw. Since the backoff may be caused by either DST_BUSY or CHAN_BUSY as discussed in Section 5.3, Tw further comprises Tw(dst), the waiting time due to DST_BUSY, and Tw(chan), the waiting time due to CHAN_BUSY. The increased number of data channels directly affects the value of Tw(chan). As for Tw(chan), the available data channels are either occupied by the RSU or the other cooperative vehicular users. With deep investigation of the experimental data, we find that the first case (CHAN_BUSY due to RSU) accounts for a significant part of Tw if only one data channel is provided, and

Average data downloaded per user (MB)

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

Average data downloaded per user (MB)

1818

40 PRR V2VR MRF MaxCD

35 30 25 20 15 10 5 0 0

0.2

0.4

0.6

0.8

18 PRR V2VR MRF MaxCD

16 14 12 10 8 6 4 2

1

0

Download probability

0.2

0.4

0.6

0.8

1

Download probability

Fig. 13. Throughput per drive-thru under more realistic mobility traces.

traces using the method introduced in [24], which were verified to accurately characterize trace 3 for highway A6[B] and trace 10 for highway M50-[E] in the surroundings of Madrid, Spain. In the following part, we denote these two traces as A6-3 and M50-10, respectively, in which A6-3 represents a dense trace while in M50-10, the interspacing between vehicles is much more sparse. In these traces, the distribution of the inter-arrival time between vehicles was generated according to a Gaussian-exponential mixture model as proposed in the aforementioned paper. The traffic generator in NS2 is revised to generate the traces as required. Each vehicle moves under constant speed and overtaking is currently not taken into consideration. This assumption is based on the discovery that vehicles traveling together at short distances are usually with similar speeds [24]. As we only concern the vehicles that are traveling within the cooperation range, such simplified assumption would not affect the result much, since those vehicles with uncorrelated speeds are usually traveling at large distances in highway scenario.

such latency can be significantly reduced if one more data channel is available, which explains the great performance gain from MaxCD (1) to MaxCD (2) in Fig. 12. While Tcache can benefit from more available data channels owing to the alleviated contention from the other cooperators, the effect is not distinct. This is because in most cases, there are not so many concurrent data flows within each other’s interference range. 6.7. Performance re-evaluation under more realistic mobility traces In the above subsections, we use synthetic mobility traces under the assumption that the inter-vehicular distance obeys exponential distribution. The advantage is that we are able to fully control different parameters so as to evaluate the performance of MaxCD from different perspectives. However, it is recently shown that this assumption may not hold in real-world highway traffic [24]. To further confirm our protocol could also perform well in more realistic environment, we generate two mobility

25 PRR V2VR MRF MaxCD

40 35

Amount of data downloaded (MB)

Amount of data downloaded (MB)

45

30 25 20 15 10 5 0

PRR V2VR MRF MaxCD

20

15

10

5

0 0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Percentile of busy vehicles (descending order)

1

0

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Percentile of busy vehicles (descending order)

Fig. 14. Individual performance gain vs. fairness under more realistic mobility traces.

1

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

We re-run our simulation using these two traces and the results are shown in Figs. 13 and 14. Comparing with Figs. 8 and 9, we can see that the performance trends are similar. MaxCD outperforms the other competitors under both dense and sparse mobility traces. In fact, our protocol is not sensitive to the inter-spacing of vehicles, as long as there are more than one vehicle within the RSU’s coverage range. The performance gain is always there as long as competition among different data flows exists and some cooperators may help. When the traffic is denser, the advantage of MaxCD becomes more obvious.

7. Related work The preliminary work on drive-thru networks mainly lies in the different kinds of measurements [1–3]. Though the feasibility of drive-thru Internet systems have been well verified, the network throughput is still limited due to the short contact time between vehicular users and the RSU. There is actually a lot of effort that has been made to improve the system performance. According to the methodology used, existing work on drive-thru networks can be roughly divided into two categories. In the first category, cooperation among vehicular users is exploited to increase the effective throughput. In [6], idle vehicles are employed as busy vehicles’ proxies. When the link quality between the busy vehicle and the RSU degrades, the proxies are involved as cooperative relays. In this way, the effective coverage range of the RSU can be extended. Other than explicitly selecting cooperative relays, the authors of [7] propose an opportunistic relay protocol to increase the downlink throughput, so as to fully utilize the link spatial diversity. While in [8], the authors find that direct transmission, cooperative relay and two-hop relay, all have their respective regions in which one of the three mechanisms works best. A novel adaptive distributed cooperative relaying MAC protocol is thus developed to maximize the system throughput, as well as the service range of the RSU. However, as mentioned in the introduction, all of these schemes aim to improve individual user’s experience, under the assumption that most of the vehicles are idle and can be employed as cooperators, without considering the effect of contention among vehicular users. In the second category, people mainly focus on the inrange scheduling and medium access control. MV-MAX, as a wireless infrastructure access control protocol for multi-vehicular communications is proposed in [15]. Each vehicle that wishes to upload data packets is required to report its SNR value of the wireless link. The RSU simply assigns the client with the highest SNR the right to transmit. Recently, another link-layer scheduling scheme [25] is proposed based on the contention-free, poll-based access mode of 802.11e. In [25], each point of the road is characterized by its packet error ratio which can be measured off-line. Under the scheduling algorithm, users with lower packet error rate will get more medium access time so as to achieve higher overall performance. In MaxCD, we jointly consider the scheduling issue in the face of multiple users’ contention, as well as cooperation. Based on the store-carry-forward delivery

1819

mechanism, we divide the protocol operation into in-range downloading and out-of-range relaying, and therefore achieve the highest throughput per drive-thru. While the above mentioned works focus on single-AP (highway) drive-thru networks, recently, more complex urban vehicular networks consist of multiple APs are discussed, in which vehicular mobility pattern is utilized to do content downloading and cooperation among vehicular users. These are thus leveraged to carry out V2V communications besides V2I downloading [26–30]. As for cooperative downloading in vehicular networks, there is actually another part of the research work that deals with mobile P2P systems [31,32,13,33], in which several (all) vehicular users are interested in the file(s) that can be downloaded from the RSUs. Each of them downloads a part of the file and they share with each other in a peer-to-peer manner when they are out of the RSUs’ service range. In this way, the file can be eventually obtained by most of (if not all) the users. It is clear that our work deals with a more general case in which each user is only interested in its own data without sharing with the others. We are thus more focused on the effective link capacity between vehicular user and the RSU in drive-thru Internet systems.

8. Conclusions In this paper, we have proposed a joint multi-flow scheduling and cooperative downloading approach (called MaxCD) to improve the network performance of drive-thru Internet systems. Focusing on download service, an efficient multi-flow scheduling scheme based on road segmentation model is proposed to resolve the in-range contention among vehicular users, and cooperation between vehicles is fully exploited to further increase system throughput. To achieve reliable and fast out-of-range relay which is the cornerstone of cooperative downloading, a collision-free multi-channel relay protocol is also developed. Through theoretical analysis and extensive simulation, MaxCD is demonstrated to be more efficient than existing strategies. Each vehicle is able to get more data that can be downloaded per drive-thru, and the relay scheme also works quite well leveraging on multi-channel communication. References [1] J. Ott, D. Kutscher, Drive-thru Internet: IEEE 802.11b for ‘‘automobile’’ users, in: Proc. IEEE INFOCOM, 2004. [2] V. Bychkovsky, B. Hull, A. Miu, H. Balakrishnan, S. Madden, A measurement study of vehicular internet access using in situ Wi-Fi networks, in: Proc. ACM MobiCom, 2006, pp. 50–61. [3] D. Hadaller, S. Keshav, T. Brecht, S. Agarwal, Vehicular opportunistic communication under the microscope, in: Proc. ACM MobiSys, 2007, pp. 206–219. [4] B.B. Chen, M.C. Chan, Mobtorrent: a framework for mobile internet access from vehicles, in: Proc. IEEE INFOCOM, 2009, pp. 1404–1412. [5] P. Deshpande, A. Kashyap, C. Sung, S.R. Das, Predictive methods for improved vehicular WiFi access, in: Proc. ACM MobiSys, 2009, pp. 263–276. [6] J. Zhao, T. Arnold, Y. Zhang, G. Cao, Extending drive-thru data access by vehicle-to-vehicle relay, in: Proc. ACM VANET, 2008, pp. 66–75. [7] J. Yoo, B.S.C. Choi, M. Gerla, An opportunistic relay protocol for vehicular road-side access with fading channels, in: Proc. IEEE ICNP, 2010.

1820

S. Yang et al. / Computer Networks 57 (2013) 1805–1820

[8] T. Zhou, H. Sharif, M. Hempel, P. Mahasukhon, W. Wang, T. Ma, A novel adaptive distributed cooperative relaying MAC protocol for vehicular networks, IEEE Journal on Selected Areas in Communications 29 (1) (2011) 72–82. [9] M. Heusse, F. Rousseau, G. Berger-Sabbatel, A. Duda, Performance anomaly of 802.11b, in: Proc. IEEE INFOCOM, 2003, pp. 836–843. [10] X. Liu, E. Chong, N. Shroff, A framework for opportunistic scheduling in wireless networks, Elsevier Computer Networks 41 (4) (2003) 451–474. [11] C. SCC32, IEEE p1609.4 Standard for Wireless Access in Vehicular Environments (WAVE) – Multi-Channel Operation, Draft Standard, IEEE Intelligent Transportation Systems Council, 2006. [12] The Network Simulator NS-2. . [13] J. Zhang, Q. Zhang, W. Jia, VC-MAC: a cooperative MAC protocol in vehicular networks, IEEE Transactions on Vehicular Technology 58 (3) (2009) 1561–1571. [14] N. Wisitpongphan, F. Bai, P. Mudalige, V. Sadekar, O. Tonguz, Routing in sparse vehicular ad hoc wireless networks, IEEE Journal on Selected Areas in Communications 25 (8) (2007) 1538–1556. [15] D. Hadaller, S. Keshav, T. Brecht, MV-MAX: improving wireless infrastructure access for multi-vehicular communication, in: Proc. ACM CHANTS, 2006, pp. 269–276. [16] W.L. Tan, W.C. Lau, O. Yue, T.H. Hui, Analytical models and performance evaluation of drive-thru Internet systems, IEEE Journal on Selected Areas in Communications 29 (1) (2011) 207– 222. [17] S. Biswas, R. Morris, EXOR: opportunistic multi-hop routing for wireless networks, in: Proc. ACM SIGCOMM, 2005, pp. 133– 144. [18] S. Chachulski, M. Jennings, S. Katti, D. Katabi, Trading structure for randomness in wireless opportunistic routing, in: Proc. ACM SIGCOMM, 2007, pp. 169–180. [19] M.-H. Lu, P. Steenkiste, T. Chen, Design, implementation and evaluation of an efficient opportunistic retransmission protocol, in: Proc. ACM MobiCom, 2009, pp. 73–84. [20] A. Balasubramanian, R. Mahajan, A. Venkataramani, B. Levine, J. Zahorjan, Interactive WiFi connectivity for moving vehicles, in: Proc. ACM SIGCOMM, 2008, pp. 427–438. [21] T.K. Mak, K.P. Laberteaux, R. Sengupta, A multi-channel VANET providing concurrent safety and commercial services, in: Proc. ACM VANET, 2005, pp. 1–9. [22] Y. Bi, K.-H. Liu, L. Cai, X. Shen, H. Zhao, A multi-channel token ring protocol for QoS provisioning in inter-vehicle communications, IEEE Transactions on Wireless Communications 8 (11) (2009) 5621– 5631. [23] Q. Chen, F. Schmidt-Eisenlohr, D. Jiang, M. Torrent-Moreno, L. Delgrossi, H. Hartenstein, Overhaul of IEEE 802.11 modeling and simulation in NS-2, in: Proc. ACM MSWiM, 2007, pp. 159–168. [24] M. Gramaglia, P. Serrano, J.A. Hernandez, M. Calderon, C.J. Bernardos, New insights from the analysis of free flow vehicular traffic in highways, in: Proc. IEEE WoWMoM, 2011, pp. 1–9. [25] J. Alcaraz, J. Vales-Alonso, J. Garci, a Haro, Link-layer scheduling in vehicle to infrastructure networks: an optimal control approach, IEEE Journal on Selected Areas in Communications 29 (1) (2011) 103–112. [26] S. Yoon, D.T. Ha, H.Q. Ngo, C. Qiao, MoPADS: a mobility profile aided file downloading service in vehicular networks, IEEE Transactions on Vehicular Technology 58 (9) (2009) 5235–5246. [27] F. Malandrino, C. Casetti, C.-F. Chiasserini, M. Fiore, Content downloading in vehicular networks: what really matters, in: Proc. IEEE INFOCOM, 2011, pp. 426–430. [28] O. Trullols-Cruces, M. Fiore, J.M. Barcelo-Ordinas, Cooperative download in vehicular environments, IEEE Transactions on Mobile Computing 11 (4) (2012) 663–678. [29] F. Malandrino, C. Casetti, C.-F. Chiasserini, M. Fiore, Offloading cellular networks through ITS content download, in: Proc. IEEE SECON, 2012, pp. 263–271.

[30] D. Zhang, C.K. Yeo, Enabling efficient WiFi-based vehicular content distribution, IEEE Transactions on Parallel and Distributed Systems 24 (3) (2013) 479–492. [31] A. Nandan, S. Das, G. Pau, M. Gerla, M. Sanadidi, Co-operative downloading in vehicular ad-hoc wireless networks, in: Proc. IEEE WONS, 2005, pp. 32–41. [32] U. Lee, J.-S. Park, J. Yeh, G. Pau, M. Gerla, Code torrent: content distribution using network coding in VANET, in: Proc. ACM MobiShare, 2006, pp. 1–5. [33] M. Li, Z. Yang, W. Lou, Codeon: cooperative popular content distribution for vehicular networks using symbol level network coding, IEEE Journal on Selected Areas in Communications 29 (1) (2011) 223–235.

Shengbo Yang received his B.E. in electronic engineering and information science from University of Science and Technology of China, Hefei, China in 2008. He is currently working toward the Ph.D. degree at School of Computer Engineering, Nanyang Technological University, Singapore. His research interests include routing in challenged mobile ad hoc networks, delay tolerant networks and vehicular networks.

Chai Kiat Yeo received the B.E. (Hons.) and M.Sc. degrees in 1987 and 1991 respectively, both in electrical engineering, from the National University of Singapore and the Ph.D. degree from the School of Electrical and Electronics Engineering, Nanyang Technological University (NTU), Singapore, in 2007. She was a Principal Engineer with Singapore Technologies Electronics and Engineering Limited prior to joining NTU in 1993. She has been the Deputy Director of Centre for Multimedia and Network Technology (CeMNet) in Nanyang Technological University (NTU), Singapore. She is currently Associate Chair (Academic) with the School of Computer Engineering, NTU. Her research interests include ad hoc and mobile networks, overlay networks, speech processing and enhancement.

Bu Sung Lee received the B.Sc. (Hons.) and Ph.D. degrees from the Electrical and Electronics Department, Loughborough University of Technology, UK, in 1982 and 1987, respectively. He is currently associate professor with the School of Computer Engineering, Nanyang Technological University, Singapore. He was elected the inaugural President of Singapore Research and Education Networks (SingAREN) and has been an active member of several national standards organizations, including the National Grid Pilot Project and international organizations such as Asia Pacific Advanced Networks (APAN). His research interests include computer networks protocols, distributed computing, network management and grid computing.