======= Review 1 ======= > *** Strengths: What are the major reasons to accept the paper? [Be brief.] The work proposes three methods to select vehicles in charge of gathering data from neighbors in order to forward them to roadside access points. The framework aims at reducing traffic load on the cellular network while maximizing the set of vehicles whose data are collected. The problem is really interesting, the proposed solutions seem sound and their performance is evaluated with real data. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] I can't see any serious drawback in this work. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. A few typos should be corrected: - p.1, last paragraph of second column: "we explore the above A scenario" ("a" should be withdrawn) - p.2, beginning of first column: "Their downlink nature makeS" - p.2, last paragraph of sec.I: "exploit to study the the FCD offloading" (withdraw one "the") - p.4, beginning of second column: "we apply THESE four algorithms to our vehicular trace". As the algorithms have been cited in the previous column, I'd rather write "we apply the four algorithms discussed above". - Sec.IV.A: in the first paragraph (p.5), you define the probability of transmitting on a cellular link as k/D_i. But you don't define k. For the sake of clarity, you should specify that k is a parameter whose value impacts on the number of vehicles covered, and that you look for good values of k in the following. - fig.8 is quite confused. In the caption you say that you represent the vehicles in the transmitting set. Actually -- if I correctly understand -- black/gray curves represent the gain obtained, and red/pink curves the percentage of covered vehicles. So, you should correct the caption. > *** Recommendation: Your overall rating. Accept (4) ======= Review 2 ======= > *** Strengths: What are the major reasons to accept the paper? [Be brief.] Well written. Interesting problem. Valuable solution. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] In some Sections, the exposition of concepts should be improved for clarity. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. This paper presents a simulation-based study on the effectiveness of local offload of float-car-data (FCD) gathering by means of vehicle-to-vehicle (V2V) communications. A subset of the circulating vehicles is selected to act as relay for the remaining ones in the collection and upload of the sensed data to the cellular network. The data will be then forwarded to the end-user control center. The gain resides in the reduction of long range (with respect to the V2V ones) transmissions between distinct vehicles and the cellular base station. The paper is based on a convincing simulation scenario, it clarifies the metrics used for analyzing the network, and proposes convincing practical protocols to achieve the potential gain of FCD techniques. My overall recommendation is to accept the paper for inclusion in WoWMoM. Some improvements, in this reviewer's opinion, are advisable: The paper is well written except for the section describing the practical solutions, and in particular Section IV B. Some improvements here and there are needed to improve the paper clarity and readability: 1) I don't like the choice of the cumulative distribution function to represent several metrics. I really cannot figure out why an histogram of the simulation outcomes is not used in Figures 3 and 5 to represent the distribution of the network degree and of the achieved gain. One reason could be that such an histogram would present an irregular profile, but this could be circumvented just reducing the resolution on the horizontal axis, i.e. increasing the size (and reducing the number) of the representing bins of the histogram. In this reviewer's opinion, such a choice would increase the readability of the analysis presented in Section III. 2) At the beginning of Section IV a) there is the need to clarify that $k$ is a system parameter subject to optimization and which involves a trade-off between coverage and offloading gain. In the current version, this only becomes clear in the following page. 3) The cost of local communications is never taken into account. I believe this choice should be clearly stated, at least in Section IV B, where a cost-optimization problem is cast to obtain the optimal value of the parameter k. 4) The description of the degree-based with confirmation algorithm (see below) need some improvement. In particular, I think that the random components of the problem should be clearly stated. They are: a) the topology, and b) the random choice of nodes for upload to the BS or not. It should then be clearly said that Eq. 4 is the *average* cost of a single node, where the average is performed over both random components. Furthermore, the text following Eq. 5 is misleading, since it speaks about "those nodes that are sure to be selected" and similar expressions to address the components of the RHS of Eq. 5. Now, Eq. 5 is basically a different way to write Eq. 4, and the text explaining it should clarify that: * it refers to the FCD of a *single* node, and in particular to the cost associated to the events that can occur at such node. * The probability for a node to transmit is k/d. Where d (the number of neighbors) is, in turn, randomly determined by the topology (with probability $\pi_d$). * then, If d turns out to be less than or equal to k, the node will surely transmit (the associated cost is the first term of the RHS of Eq. 5). * The same lines should be followed to describe the terms in the second sum in Eq. 5. 5) About the description of the performance of the DB-C in the first part of the second column of page 7: it is said that the rush hours are those where *the mechanism has the most difficulties in approaching the optimal solution*, this seems to contradict Fig. 9b, where it looks like the performance of the DB-C are closer to the optimal value (i.e, is more effective) exactly in the rush hours. A more set aided description of the content of the paper follows: The study relies on a database which collects a the patterns of the vehicles circulating in the city of Köln, Germany, over 24 hours (a working day). The database is used as a basis to generate traffic patterns using using dedicated simulation tools, resulting in a meaningful enlarged data set. First of all, an analysis of the synthetically generated data-set is performed through a graph-theory approach, in terms of the probability distribution of the vertex degree and of the so called network assortativity. Such metrics are selected because they are representative of the capability of network nodes to collect traffic for others. The objective of a protocol for traffic offloading is the maximization of the gain defined in terms of the percentage of the circulating vehicles that can benefit of a relay to upload FDC to the network. The problem is cast in terms of maximization of such a gain and it is showed that this is essentially a minimum dominating set search problem, known to be np hard. Four suboptimal algorithms are then compared in terms of the gain they are able to offer. All such algorithms are based on an oracle-like knowledge of the network topology: the main contribution here, is to show that behave similarly, providing a rough indication on the behavior of maximum optimal gain (which is not available due to the NP hardness of the problem). The average distribution of the gain is first showed, its evolution over the 24 period is analyzed, along with its geographical distribution. The result is that the potential gain increases in peak traffic hours and in dense areas, i.e. it is possible to offload the cellular network of FCD traffic in the exact place and times where and when the risk of congestion is higher. The second part of the paper presents practical solutions based on only local topology knowledge, the degree-based (DB), degree-based with confirmation (DB-C), and reservation based (RB). The first solution is based on autonomous decisions by each node, which chooses wether to upload or offload to neighbors its own FCD. The probability to choose for transmitting own data by a node is controlled by a system parameter k and inversely proportional to the number of neighbors. This solution is simple but leaves it open the possibility that several nodes will not upload their FCD. It is interesting how the authors use the assortativity property to obtain approximate expression of the coverage ratio. The DB-C is based on the DB, but it is able to guarantee 100% coverage. The RB solution is essentially a distributed implementation of the LFMIS algorithm, with a reservation phase and a transmit phase in each FCD-upload period. The performance computation of such protocol, based on the approximation that the network be grouped in cliques of d nodes, is worth and interesting. > *** Recommendation: Your overall rating. Accept (4) ======= Review 3 ======= > *** Strengths: What are the major reasons to accept the paper? [Be brief.] This pape proposes to use V2V communications to aggregate and transmit Floating Car Data back to the vehicle manufacturers or more in general to the proper sync. I think the modeling approach taken by the authors is both the strong and weak point of this paper. Its very simplistic to represent the reality of things yet allows to get a rough estimation of the V2V benefits in this case. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] - Model is very simplistic - the idea is not entirely new, is just another instance o the many proposal on urban sensing, authors should check the work done by Gerla, by Lee and Gerla, by Martin Mauve, etc. - the paper fails to clarify how the reduction of data is performed. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. - as also admitted by the authors considering the propagation a round circle is not really a good idea in urban scenarios. - The model based on dynamic graph highly relies on the mobility model that is itself a simulation. In particular it is not clear not even from the reference [13] the vehicle distribution among roads, i.e. how statistically they fall in major roads, or other roads including small roads. - Another question is the following. Given that the collective set of data among a number of V2V connected vehicles is 100MB, how this approach can reduce it to 10MB without loss of information? The Car Floating data, is usually data from CanBus, and while can be classified is peculiar of each car. Authors may claim you do not transmit parameters that are within the norm but this would reduce the ability of preventive maintenance on the base of fault correlation. Reading along the paper I can't understand how the data set is reduced. In other words i buy the fact that you reduce the number of vehicles accessing the network hence reduce the number of 3G/LTE customers attached to the infrastructure, but how you actually reduce the amount of data without loosing the semantics of it? > *** Recommendation: Your overall rating. Likely Reject (2) ======= Review 4 ======= > *** Strengths: What are the major reasons to accept the paper? [Be brief.] Complete work, uses real data as basis of evaluation. Work seems correct. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] Not clear why this is a useful area to work on. No comparison to other approaches. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. Overall the paper is well written and the work seems correct. Using real data as basis of your evaluation is very good. However, the overall motivation of the whole problem is rather confusing. You only allude vaguely to possible applications that might require FCD in the sense that you consider in this paper, i.e., instant real-time access to every vehicle. What applications would require this? You mention that similar problems have been considered for downstream traffic, but then claim that your case, upstream, is "semantically different". What exactly does that mean? A priori, both downstream and upstream are about saving capacity on the wireless link. Why won't solutions for downstream cases be applicable to your situation? The paper should perhaps focus on motivating the need for your solution rather than simply taking it as a starting point and developing different algorithms on top of it. For example, it is true that the amount of mobile data will increase, but if data due to FCD is a small fraction of the total data traffic, then there is no need for a solution like yours. Can you give any kind of estimates about how much traffic would come form FCD and what fraction of total mobile data traffic it could represent? Another possible solution would be to use sampling, i.e., only a fraction of cars send their data. This would easily be sufficient for things like traffic or environmental monitoring, etc., which you seem to consider as applications. This would obviate the need for complex car-to-car communications. Why is this not a workable solution? You motivate DB-C by saying that some applications might require 100% coverage. What are those applications? What happens in RB if cars move in and out of communication range during the algorithm? Your evaluation only considers your own solution, but does not compare against any other solutions in the literature. Given the parallels to downstream offloading and DTNs, there should be many solutions to compare against and this might help show that your case really is different from existing cases. In the paper you only state that your case is different, but provide no kind of evidence or insight why that is so. > *** Recommendation: Your overall rating. Likely Reject (2) ======= Review 5 ======= > *** Strengths: What are the major reasons to accept the paper? [Be brief.] 1. An important problem of offloading data upload tasks from cellular networks to vehicle-to-vehicle networks is addressed. 2. Nice problem formulation, learning lessons from an optimal algorithm, and using the lessons learned in designing a set of distributed algorithms. 3. Evaluation performed using real data collected from vehicles in a city. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] 1. It is not clear what sort of fusion is performed on the vehicular data. It is important to understand the underlying fusion mechanism since it determines the usage of the cellular network when vehicles individually use the cellular network or when the fused data is offloaded from a single vehicle. 2. The paper makes a big claim about real time data offload and fusion, however, it just talks about a single snapshot of the network graph and analyzes all the algorithms on it. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. The paper presents a set of techniques for using V2V communication to perform in-network data fusion to minimize the use of the cellular network. The key idea is to find an alternative to transmitting data from individual vehicles, that might overuse the backhaul bandwidth. The paper treats the problem really well. For instance, real data is used to derive metrics governing the algorithms. A centralized oracle based optimization framework is used to derive underlying properties that should govern a near-optimal distributed algorithm. All three proposed algorithms are tested on real data, and shows good performance. Overall, this paper is a good fit for WoWMom---hence, my Accept Recommendation. However, there are elements of the paper that can be improved. For instance, just looking at the number of vehicles that do not participate in direct communication with cell towers may not be an appropriate metric. For instance, whether the amount of data transferred on performing data fusion is comparable to the amount of data transferred when individual vehicles send data is application dependent. In a practical monitoring application, for instance, it might be important to collect data at a fine granularity at certain locations and fusing data from a set of vehicles might not suffice. The biggest draw back of the paper, however, is the lack of emphasis on real time data collection. While the paper is motivated by real time data collection inspite of in-network aggregation, at the end, the paper just analyzes a snapshot of the network. This was disappointing. Inspite of the above caveats, this is decently well thought through paper that addresses an interesting problem. > *** Recommendation: Your overall rating. Accept (4) *********************************************************************************************************************************************************************************************** Comments for previous version submitted at INFOCOM 2013 *********************************************************************************************************************************************************************************************** ======= Review 1 ======= > *** Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper. The paper considers the problem of collecting data generated in cars and proposes a scheme where cars first use V2V communications to collect and fusion data and then only the collector sends the data over a mobile (phone) network. The paper focuses on presenting three solutions for determining who should transmit the data. Car generated data will increase in the future, but it is not clear if the approach in this paper is relevant in that future. Novelty of the solutions is somewhat lacking and in general the motivation and reasoning behind the problem are rather disappointing (see comments below). The depth is a bit shallow since only three, rather simple, solutions are considered and no clear insights result from the work. > *** Strengths: What are the major reasons to accept the paper? [Be brief.] The paper is technically correct. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] Motivation for the work is very weak and is not based on reality. Not much depth in solution. Feels like a solution looking for a problem. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. The paper is in general quite easy to read and follow. It is written clearly and the solutions are nicely presented. My main issue with the paper is that it is not clear why your solution is needed in the first place. You simply state that the mobile network will not be able to handle the amount of traffic, but do not justify this based on any real, numerical data. Even a back-of-the-envelope calculation on the (data) traffic numbers would be helpful in understanding whether this is a problem worth solving. You mention as possible applications insurance companies basing their premiums on driving style or accident investigations, but why would either of these cases require a real-time transmission of data? Why is it not sufficient to collect the data in a black box, for example, and transmit the data overnight when the car is parked and the network is quiet? For live traffic applications, such as congestion or accident notifications, does every car really need to participate? Why do you not evaluate a solution where only a fraction of the cars participate and then see how does this affect the quality of results for the system as a whole? This would obviously require you to define a concrete application as opposed to simply looking at an abstract mathematical model, but would make the paper a lot stronger. One example of such an application is presented in Crepaldi et al. "QuickSilver: Application-driven Inter- and Intra-cluster Communication in VANETs" in MobiOpp 2012. That work takes a slightly different approach to a similar problem. You state that your problem is different from downloading or WiFi offloading, but how exactly is your problem (effectively uploading) different from downloading? Aren't there similar capacity issues in both directions, so what makes this problem unique and why won't solutions for downloading work here? One justification for DB-C is that some applications might require 100% coverage. Can you provide examples of such applications? How does RB algorithm handle mobility of cars in and out of the coverage area during one round of collection? Figure 8 is hard to read because the lines fall on top of each other. "Floating Car Data" is not a widely used term so its use in the beginning of the abstract without any explanation is confusing. Typos: - assurance -> insurance - tour (page 4) -> should this be round? > *** Recommendation: Your overall rating (Please try giving as few borderlines as possible). D = (bottom 50% of reviewer's perception of all INFOCOM submissions) - reject (1) ======= Review 2 ======= > *** Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper. This paper presents methods to aggregate vehicular information. More and more data will be generated by vehicles for various purposes. Uploading these data using 3G or 4G network is expensive and will be a burden for the network. This paper first finds properties of vehicular networks based on a large driving data set. Then it presents the idea of aggregating data locally before sending it to the internet. The objective is defined as minimizing the fraction of vehicles that have to access the cellular infrastructure. The problem is modeled as finding the vehicle to transmit the data to the cellular network, which essentially is a a vertex cover problem. The authors first provide an oracle based solution using a classical greedy algorithm assuming that the global vehicular network structure is known. Then the paper presents three localized solutions to this problem. The first one is a degree based solution in which a vehicle transmits with probability k/D, where k is a constant and D is the degree of the vehicle in the network. However, it does not guarantee all the nodes transmit or have a one-hop neighbor to transmit. In the second solution, a vehicle transmits when there are no neighboring nodes transmitting. In the third solution, the nodes will run a protocol (similar to 802.11 MAC protocol) to select the transmitter. Simulation shows 95% of traffic can be offloaded in the best case. > *** Strengths: What are the major reasons to accept the paper? [Be brief.] Uses real data sets to evaluate the performance of the presented heuristics. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] The heuristics are trivial. The contribution of the work is small, given that dominating sets have been studied extensively in the past. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. Delay is not studied in this paper. It is an important metric as well. > *** Recommendation: Your overall rating (Please try giving as few borderlines as possible). C = (top 50% of reviewer's perception of all INFOCOM submissions, but not top 30%) - weak reject (2) ======= Review 3 ======= > *** Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper. In this paper, authors study the celluar traffic offloading problem in vehicular networks. This paper mainly focus on the upload traffic for the floating car data transmission. Authors analysis the real traces collected in Germany and observe the potential gain of vehicle-to-vehicle communications to traffic offloading. Two offloading schemes are proposed and trace-driven simulations are conducted to validate the results. > *** Strengths: What are the major reasons to accept the paper? [Be brief.] Real traces of vehicle trajactories are analyzed in this paper. The paper is well-written and organized. Trace-driven simulations are conducted. > *** Weaknesses: What are the major reasons NOT to accept the paper? [Be brief.] The authors somehow over-claimed their contributions, though may not be intentionly. Related works are not sufficient. No comparisions with the existing works are conducted. > *** Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors. In this paper, authors study the celluar traffic offloading problem in vehicular networks. This paper mainly focus on the upload traffic for the floating car data transmission. Authors analysis the real traces collected in Germany and observe the potential gain of vehicle-to-vehicle communications to traffic offloading. Two offloading schemes are proposed and trace-driven simulations are conducted to validate the results. Overall, the paper is well-written with clear presentation and paper organizations. The main weaknesses of the papers are as follows. First, authors claimed that they were the first the explore the v2V communications to offload the celluar traffic. We have to say this is not the first. Notice that from the V2V communication perspective, DSRC is not the only option and all short range communications can be employed. In this regard, WIFI can also be used as the v2v communciation method. In other words, celluar traffic offload using Wifi networks (e.g., in an ad-hoc manner) are not completely different from this work. There have been tons of paper discussing how to offload uplink/downlink celluar traffic using WIFI ad-hoc manner. See "Utilizing shared vehicle trajectories for data forwarding in vehicular networks" as an exampled ref. Second, as authors narrow their related work to the DSRC-based v2v communications, the related works are not sufficient to cover all. Indeed, the design in this paper have been widely advocated and researchers now consider more practical issues. For example, two vehicles are not necessary to communciation even there is a contact because of the too short contact time. Vehicles in the same direction may provide more v2v communciation capacity, and less for different dirrections. vehicles at the intersections may have more time to communicate, and etc. Third, as there are so many related proposals, it is not appropreite to evaluate the proposals of this paper only. Comparisions with the existing works are desired. > *** Recommendation: Your overall rating (Please try giving as few borderlines as possible). C = (top 50% of reviewer's perception of all INFOCOM submissions, but not top 30%) - weak reject (2)