Revisiting WiFi offloading in the wild for V2I applications

This paper revisits the opportunities of using WiFi offloading for Vehicle to Internet (V2I) communication, and how this has changed over the last decade. With the rollouts of provider-managed WiFi networks that are more structured and operate under authenticated regimes, WiFi offloading, or use of available (roadside) WiFi networks for V2I data communication, has different opportunities and challenges. To study the current landscape,we develop a system ( X-Fi ), which efficiently selects, associates to, authenticates with, and performs WiFi offloading for V2I communication with these networks, and a tool ( X-Perf ), which illustrates opportunities of WiFi offloading available today in these networks, with measurements and experiments across four metro areas across three continents over 22 months. Our results indicate the feasibility of achieving 1 GB/hour application goodput, an order of magnitude higher than the number provided by open WiFi networks in the past, which can take a significant load away from alternative communication paths for V2I systems. Moreover, we provide several implications on transport protocols and WiFi deployments to shed light on the use of such WiFi networks for V2I communication.


Introduction
Vehicle to Internet (V2I) communication has been a topic of significant research over the years. New systems that improve V2I communication [1,2] and measurement studies of how commercial and research systems fare under the prevalent network conditions have also described the evolution of such systems [3,4]. Many efforts observed that if every vehicle were to connect and communicate with Internet-hosted infrastructure, the aggregate data volumes are likely to overwhelm common cellular capacities. Therefore, a common thread of work has also been to explore opportunistic WiFi offloading, often using open WiFi Access Points (APs). Cabernet [3], circa 2008, is a good exemplar of such a system where various location-related data from Boston taxis were uploaded using such opportunistic encounters with such open WiFi APs. The authors conducted an extensive measurement F. Yang et al. Table 1 MNOs' cellular data plans [18]. Throughput is presented in an order of downstream and upstream, which is throttled to 128 Kbps by many providers if the data cap is reached; Italian providers stop any service if consume > 100 GB/month.  1 Reducing the data rate for a specific user is a common practice among mobile network operators -in the US, high-end AT&T and T-Mobile plans have a data cap per billing cycle of 50 GB and 100 GB, respectively. Once a user reaches the data cap, their service speeds are reduced. 2 As there is currently no publicly available data on the pricing plans for connected vehicles, we take the ones for smartphones as references. We note that the pricing plans for connected vehicles may be different from the ones for smartphones in the future. But, we expect that the price will still be much higher than that of provider-managed WiFi networks, since MNOs will have CAPEX and OPEX for the infrastructures to support connected cars as for the current cellular networks. of those WiFi providers, they can subscribe to the cheapest plan of those WiFi providers, which is usually much cheaper than the common plan that provides cellular data access. For instance, the cheapest subscription offered by Free (France) is 2e per month, which is much cheaper than the common subscription (19.99e per month). 3 The ongoing transition toward 5G [19,20] and the deployment of future WiFi standards (i.e. WiFi 6) [21] are not going to change the current cost-benefit ratio. 5G cells will trade high performance at the price of coverage. Besides, 5G architecture is designed to natively integrate multi-radio access, and WiFi is one of them [22,23]. Thus, it is reasonable assuming 5G cellular access will have a per-user cost similar to LTE, with WiFi remaining a free perk of home network providers. We note that WiFi offloading alone is suitable for non-real-time bulk transfer applications. But, with some supports from multi-path transport (e.g. Multipath TCP [24], Multipath QUIC [25,26]), WiFi offloading together with cellular networks may also contribute to real-time applications.
The problem: Although the benefits of WiFi offloading in terms of costs are appealing, today's provider-managed WiFi networks introduce new challenges. For instance, the authentication and DHCP server, deployed in core networks, may be geographically distant from the APs, which introduce extra latencies that may prevent vehicular clients from quickly getting Internet connectivity. Thus, an investigation on the feasibility of offloading connected vehicles' data to provider-managed WiFi networks is of paramount importance. Further, a quantitative analysis of the transmission capability of such networks in the V2I context is also crucial for incentivizing all players in the connected vehicle arena to explore the possibility of WiFi offloading. However, all past studies [3,[27][28][29][30][31] focused on open WiFi networks or limited WiFi deployments around ten years ago, which almost no longer exist [32,33] and are fundamentally different from provider-managed WiFi deployments that are authentication-required, encrypted, more structured, and powered by more advanced networking techniques (e.g. MIMO has been introduced since 802.11n [34]).
Our solution: To fill the above gap, we present an extensive measurement study of V2I WiFi offloading feasibility in-the-wild, across 4 cities and 3 continents, covering more than 5620 km, over a period of 22 months. To conduct the measurement study, a system, X-Fi, that enables a moving car to connect to provider-managed WiFi networks, proven to work across multiple countries and operators, and a tool, X-Perf , to measure TCP performances in intermittent networks are introduced.

Main takeaway:
The key observations made by this paper are: (1) the feasibility of WiFi offloading based on provider-managed networks is confirmed; (2) while today's provider-managed WiFi networks provide comparable coverage, they offer an order of magnitude higher goodput (∼1 GB/h) than what was observed in previous studies based on open WiFi networks [3,[27][28][29][30][31]; (3) the time spent for establishing Internet connectivity via roadside APs is lengthened in provider-managed networks, compared with the one in open WiFi networks [3], due to the more complicated interactions with the authentication and DHCP server via multi-hop paths; nevertheless, it only counts for a small part F. Yang et al. (10%-18%) of the whole association duration; (4) the AP selection algorithm of stock WiFi client implementations, which solely relies on the initial signal strength (ISS), is not sufficient in the V2I context, as no correlation between the ISS and performance is observed; (5) 5 GHz APs generally offer better performance than 2.4 GHz APs when it comes to V2I WiFi offloading; (6) the ability to allow clients to retain IP addresses across associations is not a must implemented by providermanaged networks by default; thus, application designers must have this caveat in mind, and, either handle IP handovers at the application layer or adopt transport protocols (e.g. QUIC [35,36]) that tolerant IP handover; (7) BBR [37] and CUBIC [38] deliver similar application goodput; moreover, for both BBR and CUBIC, application goodput can benefit from using multiple concurrent flows.

Contributions of this paper:
To sum up, the contributions of this paper are: (1) the measurement system, including X-Fi and X-Perf , built for studying the current landscape of WiFi offloading based on provider-managed APs; (2) the one-of-its-kind dataset, which demonstrates the feasibility and capability of WiFi offloading via providermanaged networks; (3) the analysis and implications made from the dataset, which shed light on the use of provider-managed WiFi for connected vehicles. We have released the dataset 4 and the code 5 of X-Fi and X-Perf for the community to further study the vehicular WiFi offloading landscape. The remainder of this paper is organized as follows. We describe the related work in Section 2. Next, we present the measurement system in Section 3. Then, the methodology that we used for the study is presented in Section 4. After that, Section 5 gives a summary about our dataset. Thereafter, we present the detailed analysis regarding connectivity and transport performance in Section 6 and Section 7 respectively. In Section 8, we discuss the future work and the relationship between V2I WiFi offloading via provider-managed WiFi networks and other V2I communication solutions (e.g. 5G). Finally, we conclude this paper in Section 9.

Related work
Using WiFi to provide moving vehicles with Internet access has been studied by many researchers in the past. Table 2 [33]; (2) their measurement results are based on HostAP-MadWiFi, a companion that used low-level features that no longer exist. The authors of Cabernet [3] proposed a streamlined WiFi client to shorten the association overhead with transient APs from moving vehicles and an enhanced transport protocol to cope with intermittent connectivity. Soroush et al. [30] proposed to maintain concurrent associations with different APs on the same channel to enhance the performance and reliability of V2I WiFi connectivity. Again, both their evaluations were conducted based on open WiFi networks, thus, unable to reflect todays' V2I WiFi offloading landscape based on providermanaged WiFi networks. Deshpande et al. [28] performed a headto-head comparison between 3G and a commercially operated WiFi network in the V2I context. However, their setup is not in accord with the situation of current provider-managed WiFi networks, as WiFi authentication and IP acquisition are only needed once at the beginning of a whole drive in their experiments. Further, to reduce the effects of WiFi intermittent coverage, they limited the server-side TCP connection timeout to 1s. In contrast, our measurement system follows the standard WiFi association and DHCP flow, and, uses the stock TCP implementations to study today's landscape of V2I WiFi offloading based on provider-managed WiFi networks as-is.
Custom transport protocols for V2I: The authors of [3,43,44] proposed new transport protocols to hide the intermittent characteristics  Connection procedure handled by X-Fi/X-Perf . Auth., assoc., req., resp., ack., and disc. are abbreviations for authentication, association, request, response, acknowledgment, and discovery respectively. MAC auth. represents the authentication with APs, while access auth. means the authentication with the central authentication server via the EAP protocol [49]. If the connection is interrupted at any stage, the system goes back to the scanning stage. of V2I WiFi connectivity and improve the throughput of applications. More recently, Lee et al. [33] studied the usage of provider-managed WiFi networks as one of the connectivity options for MPTCP [24] to enhance the performance of low-latency applications on connected vehicles. These works require network stack upgrades and/or deployments of proxies on the Internet. Since our goals are to understand how well today's urban WiFi networks can support vehicular applications as-is, we decided to use TCP as our transport protocol that is predominantly used by existing applications. Hence, we do not impose any modification to the existing transport protocol.
Network assisted WiFi offloading for V2I: Several researchers [45][46][47][48] proposed better AP handoff mechanisms to enhance the V2I WiFi performance. However, all of them require modifications to the APs and, therefore, control over the infrastructure. In our work, we could not adopt any of their approaches as we have no control over the infrastructure.

Measurement system overview
X-Fi (Section 3.1) and X-Perf (Section 3.2) is a ready-to-deploy toolkit for WiFi offloading in-the-wild. X-Fi incorporates a set of optimizations to provide enhanced access to provider-managed WiFi networks from a moving vehicle. X-Perf is a measurement tool to study transport performance of intermittent connectivity. Fig. 1 illustrates the workflow of the toolkit.

X-Fi : connecting a moving vehicle to provider-managed WiFi hotspots
Motivation: Given that the encounters between vehicles and APs are commonly short, a WiFi system that can quickly set up connectivity with encountered APs is of great importance. Although Cabernet [3] proposed a vehicular WiFi client tuned for open WiFi networks via a set of heuristics, it does not support EAP authentication [49], which is prevalent in current provider-managed WiFi networks and is more suitable for vehicular uses than WEB-based authentication. On the other side, the mainstream WiFi systems for connectivity setup, such as wpa_supplicant and dhcpcd on Linux, support EAP authentication, but, they are not well-tuned for vehicular uses. Therefore, we propose X-Fi that consolidates the advantages from the two sides above.
X-Fi consists of two different pieces: (1) an enhanced wpa_supplicant, which uses a number of best-of-practice heuristics to speed up the WiFi association process; (2) an enhanced DHCP client (based on dhcpcd) customized for V2I.
WiFi association: The WiFi association process consists of a series of packet exchanges between the WiFi client, the AP, the EAP authentication server, and the DHCP server as shown in Fig. 1. Given that the vehicular WiFi connectivity has high loss rates in the fringe area of an AP's coverage [41], the WiFi client needs to retransmit the lost packets as fast as possible. As wpa_supplicant uses the timeout/retry mechanism to detect and retransmit lost packets, the proper setting of the timeouts is crucial. Therefore, we shortened the timeouts in wpa_supplicant to 100 ms and the max retry limit to 5 times, as suggested by Cabernet [3].
Besides the changes on timeouts, we also optimized the AP scanning strategy of wpa_supplicant via opportunistic active scans. X-Fi normally uses passive scans where the WiFi client dwells on each channel for around 80-100 ms to listen for beacons from nearby APs to get a full list of nearby APs. Then it tries to associate with the AP with the highest Signal-to-Noise Ratio (SNR). If this association fails, X-Fi will try to launch an active scan on the channels that have other APs with target ESSIDs, 6 (this information was learned from the previous passive scan). The rationale behind this heuristic is that the vehicle is likely still in the range of those APs' coverage, thus, no need to waste time on scanning other channels. If this active scan does not find any AP with a target ESSID, X-Fi goes back to a full passive scan. Otherwise, X-Fi tries to associate with the AP with the highest SNR. If this association still fails, X-Fi can repeat the active scan and association process as long as there still are channels that have untried APs with target ESSIDs and the time since the last passive scan has not exceeded a threshold. In our experiments, we configured this threshold to 5 s, considering that the median AP coverage is 50-100 m (see Fig. 5(b)) and 30 km/h is a typical speed of cars running in urban areas.

IP address acquisition:
Once the supplicant has established L2 connectivity to the access point, it is necessary for the client to obtain an IP address in order to communicate with other hosts on the Internet. This is done through the DHCP. The off-the-shelf DHCP client, i.e. dhcpcd on Linux, is not tuned for vehicular environments. Specifically, the inefficiency of dhcpcd mainly comes from two perspectives: (1) the timeouts for DHCP messages are too long for vehicular scenarios as demonstrated by Cabernet [3]; (2) the ARP probing mechanism, sending ARP probe packets to check whether the assigned address is in-use by other clients in the same LAN [50], is enabled by default, which may lengthen the IP acquisition process by several seconds. Therefore, we implemented a custom DHCP client based on dhcpcd that has shortened timeouts and disables the APR probing mechanism. We note that the timeouts are set to 100 ms in our DHCP client, as it is the value recommended by Cabernet [3].

Evaluation of X-Fi:
We compared X-Fi with the off-the-shelf WiFi system for connectivity setup, wpa_supplicant /dhcpcd, to demonstrate the efficiency of X-Fi. The experiments were done as follows. We equipped a car with an on-board computer (see Section 4.2 for more details about the hardware). Then, we drove the car for 10 laps following a fixed route in Bologna (the driving time is around 6 h in total), where we used X-Fi for connectivity setup for half of the laps and the wpa_supplicant /dhcpcd suite for the other half of the laps. For every WiFi association, we recorded the ''time until IP acquisition'' that means the time spent for the WiFi association and DHCP process in total. The results are shown in Fig. 2: X-Fi is significantly faster than the vanilla wpa_supplicant /dhcpcd suite with default configurations. The major improvement comes from disabling the ARP probing mechanism in DHCP, while the other heuristics, e.g. shortened timeouts, improve the tail latency of connectivity setup.

X-Perf : measuring transport performance over intermittent connectivity
TCP underpins the vast majority of internet applications. Therefore, studying TCP performance over WiFi V2I scenarios is of paramount importance. The popular TCP performance measurement tool, iPerf, lacks intermittent networks support. 7 Specifically, iPerf has two problems: (1) it cannot continue the transmission session if an IP handover caused by an AP handoff happens; (2) even if the vehicle's IP address does not change after the interruption caused by an AP handoff, iPerf can take a very long time to resume the transmission because the TCP RTO timer may increase to a very large value. Therefore, to make full use of the transient transmission window of V2I intermittent connectivity to test the TCP performance of WiFi offloading without assuming that the WiFi networks support IP roaming, we designed X-Perf , a dedicated performance measurement tool for intermittent networks.
The working process of X-Perf is illustrated in Fig. 3. Once X-Perf is up and running, it executes gpxlogger and X-Fi, respectively to track GPS coordinates and to start the attempts to associate with WiFi hotspots. Then, X-Perf monitors the status of the WiFi interface operated by X-Fi. Once the network interface obtains an IP address, X-Perf starts to probe the performance of TCP over the wireless link. Specifically, it first decides the transmission configuration for the following TCP bulk transfer, which is randomly selected from a predefined configuration pool. We note that the transmission configuration includes the direction of the transfer (upload or download), the TCP congestion control algorithm (CCA), and the number of concurrent TCP flows (flow number). By supplying different configurations to the configuration pool, X-Perf allows us to study the impact of different parameters on TCP performance. Thereafter, it measures the TCP throughput by performing data bulk transfers between a remote server and the local onboard computer. During the TCP transmission, all exchanged TCP packets are recorded by tcpdump at the client-side. As soon as X-Perf finds that the WiFi interface has lost its IP address, which means that the WiFi connectivity is interrupted, X-Perf stops the TCP throughput measurement and archives all data collected in this measurement run. The collected data contain a wealth of information from L2 to the application layer including packet-level traces, and all information is also geo-referenced and synced with GPS. X-Perf repeats the above process each time X-Fi connects to an AP until the end of the experiment or until the vehicle is turned off. 7 https://github.com/esnet/iperf/issues/835.

Measurement methodology
In this section, we detail our the methodology of our measurement study. First, an overview of the cities selected for our measurement activities is presented in Section 4.1. Next, we describe our measurement apparatus setup in Section 4.2. Thereafter, the metrics used for data analysis are introduced in Section 4.3.

Cities selected for measurement
To understand the state-quo of V2I WiFi offloading across different traffic patterns and networking infrastructures, we conducted our measurement activities across four different cities in Europe (Bologna and Paris), in Asia (Macao), and in North America (Los Angeles). The diversity of the cities enables us to collect measurements in radically different urban scenarios, traffic patterns, and viability. Specifically, Bologna is a good sample of a medium-size touristy medieval city with narrow streets, which have an unpredictable traffic pattern. Macao is, again, a medium-size city characterized by a number of high-rise buildings as skyscrapers and casinos. Paris is an extremely touristy and crowded metropolis with a well-defined city center. Los Angeles (LA) is a very populated megalopolis, with an alternating of residential areas, working districts, and rural regions.
In each city, we subscribed to one or more local providers offering access to urban WiFi APs. This gave us the WPA credentials/SIM cards needed to authenticate and connect while driving. Different cities, and different providers, have different authentication strategies: PEAPv0/EAP-MSCHAPv2 [51] in Bologna, LA, and Macao; EAP-SIM [52] in Paris. Besides, the access point deployment strategies that we encountered during our data collection can be grouped into two main approaches: (1) leveraging existing hardware installed in customers' premises; (2) installing new dedicated APs. In the first approach, the providers rent the APs to their subscribers. The rented APs present two different ESSIDs when in operation. While one is exclusively used by the customers and secured with WPA/WPA2-PSK [53], the other serves as a WiFi hotspot for public users. Therefore, both the physical capacity of the 802.11 channel and the available bandwidth of the connection, result to be shared between private customers and public users. Quality of Service rules, as token-bucket algorithms, may be applied to prioritize the customers. On the other hand, the second deployment strategy consists of the installation, done by the network providers, of dedicated APs at either indoor or outdoor spots.

Measurement apparatus setup
Hardware: The computer used for the data collection is a Slimpro SP675FP Fanless Mini PC. It features an Intel x64 3rd Gen Core processor, a 3 × 3 MIMO full-size Mini PCIe 802.11n card (WLE350NX-7 A), an u-Blox EVK-7N GPS unit, 16 GBs of RAM, and 300 GBs of SSD for storage. While for the deployment in Macao we adopted three dipole antennas, in Bologna, Los Angeles, and Paris, we opted for three multipolarized antennas. Using different antennas in Macao was not possible due to constraints imposed by the vehicle supplier; it is noteworthy that this limitation slightly affected the X-Fi performance in the Macao scenario.
Software: The onboard computer runs Ubuntu 16.04.1 with 4.10.0-33generic Linux kernel. At the computer boot, systemd launches X-Perf (Section 3.2). Once up, it executes gpxlogger and X-Fi (Section 3.1), respectively to track the GPS coordinates and to start the association and connection attempts with nearby WiFi hotspots. Thereafter, X-Perf starts measuring the performance of WiFi offloading and collecting measurement results as explained in Section 3.2. We configured X-Perf to use the following configuration pool (explained in Section 3.2): CCA ∈ {BBR, CUBIC}, direction ∈ {upload, download}, flow number ∈ [1,16]. BBR [37] and CUBIC [38] are chosen because the two are now the predominant CCAs on the Internet [54]. BBR is a recent work adopted by many Google services and outperforms classic window-based CCAs across various scenarios, especially over lossy links. CUBIC is window based and is the default Linux congestion control. This configuration pool enables us to compare different CCAs and study the impact of concurrent flows. It is noteworthy that system parameters related to Linux TCP stack (e.g. buffer size, etc.) are set by the operating system to the default values.

Permanent deployment in Macao:
In Macao, we placed the Slimpro Mini PC under the back seats of a granted van. Two WiFi antennas and the GPS antenna were installed on its roof and one extra WiFi antenna under the back seats for space concerns. The van runs errands on behalf of the granting institution and transport staff. For the whole duration of the experiment, the mobility pattern of the van remained unaltered from its usual one, allowing us to collect in-the-wild samples representative of transporters' real-world mobility. The TCP server was hosted in a virtual machine (VM) based in Singapore to reduce latency.

Short-term trial in Paris:
In Paris, we instrumented a vehicle with: three WiFi antennas and one GPS antenna placed on the roof of the vehicle, the Slimpro Mini PC located on the front seat and powered by the vehicle. A Dekart SIM card reader is used for the EAP-SIM authentication required by Free [55]. We deployed the TCP server on a machine located in Paris. The driving routes covered more than half of the districts in Paris downtown.

Short-term trial in LA and Bologna:
The vehicle used in LA was equipped as the one in Paris, except for the SIM card reader. Here, we methodically mapped both residential and commercial areas. We deployed the TCP server used for our tests on a cloud VM in LA. In Bologna, we replicated the LA setup, but with the server in Paris.

Metrics of interests
Connectivity: Here now follows the list of metrics used to understand the characteristics of the V2I WiFi connectivity. We note that the first nine metrics are also illustrated via Fig. 4 to make them more intuitive.
• Association setup time: The time needed for the association setup process. • DHCP time: The time for the DHCP process, reflecting the overhead for IP acquisition.
• Time until the first TCP ACK: The time between the start of the association and the first TCP ACK received from the server, reflecting the total time spent for establishing end-to-end Internet connectivity.
• Link-layer connectivity duration: The time that an association lasts.
• IP connectivity duration: The duration that an association has an IP address.
• TCP connectivity duration: The time between the start and termination of a TCP session. 8 X-Perf stops a TCP session right after the WiFi interface loses its IP. Hence, the end of a TCP session coincides with that of IP connectivity.
• Link-layer connectivity hole: The idle period between two successive associations.
• IP connectivity hole: The idle period without an IP address between two successive associations.
• TCP connectivity hole: The idle period between two successive TCP sessions.
• Initial signal strength (ISS): The signal strength sensed during the WiFi scanning phase. It is the only metric considered by stock WiFi implementations during the AP selection. In a stationary case, selecting the AP with the highest ISS works well. We investigate whether this works as well, for in-motion vehicles.
• Average vehicle speed per association: The average vehicle speed during an association, which is calculated based on GPS traces and may affect the performance of V2I WiFi offloading.
• WiFi frequency: We seek to find whether there are differences between 5 GHz and 2.4 GHz APs in the context of V2I WiFi offloading.
• IP address roaming support: By analyzing the IP address at each association, we can observe how often a vehicle changes its IP (the local one) during a drive. This affects the design of applications and transport protocols for in-motion vehicles to transfer content via providermanaged WiFi networks.
Transport performance: We now present a list of the metrics used to assess the transport performance of V2I WiFi offloading.
• Average TCP goodput: The aggregated average goodput of a TCP session calculated based on pcap traces.
• Data volume: The total number of bytes that have been successfully transferred during a TCP session.

Dataset summary
The salient features of our dataset are summarized in Table 3. The WiFi networks we connected to in Bologna and Paris (Fastweb, Emilia F. Yang et al.  Fig. 5(a). Given the diversity of APs density and traffic conditions across the four cities, the average driving speeds per association are also dissimilar. In Paris, Macao, as well as in the downtown area of Bologna, where the speed limits are stricter, most of the associations happened at speeds lower than 30 km/h. Instead, outside the center of Bologna, as in LA, we had the chance to connect with outdoor APs placed along the main roads, driving at higher speed (40-62.5 km/h). Fig. 5(b) reports the CDF of AP coverage, which is the diagonal length of the smallest bounding box enclosing all GPS points collected during the associations with that AP. The APs in LA present, on average, a much wider coverage (180.17 m) than the ones in the other cities,

Connectivity analysis
This section presents the measurement results from the connectivity perspective. We first analyze the time needed for connectivity setup in Section 6.1. Next, the duration of connectivity and holes without connectivity is considered in Section 6.2. Thereafter, we analyze the impact of vehicle speed, ISS, and WiFi frequency on connectivity in Section 6.3. Finally, the IP address roaming support of each provider-managed WiFi network is analyzed in Section 6.4.

Time for connectivity setup
Association setup time: The CDFs of association setup time is reported in Fig. 6(a). In Bologna, Macao, and Paris, 90% of the association setup processes terminate in less than one second. On the other hand, on average, the association setup process in LA takes slightly longer than in the other cities. None of the distributions is heavy-tailed, with the means only lightly skewed from the medians. The data points with relatively longer association setup time are due to the re-transmissions of the packets (i.e. authentication packets) necessary for association setup.

DHCP time:
The CDF of DHCP time is plotted in Fig. 6(b). In Bologna, Macao, and Paris, the 90% of DHCP processes terminate within 1 s. As the association process, also the DHCP process in LA is slightly longer than in the other cities. The differences between cities might be caused by the ways how operators deploy their DHCP servers.
A more detailed breakdown of the phases prior to gaining IP is shown in Fig. 8(a). As expected, the DHCP and EAP authentication   account for the major part of the overhead. The reasons for this are two-fold: (1) the DHCP and EAP authentication cause more packet exchange between clients and APs than the other two; (2) during the DHCP and EAP authentication phase, clients communicate with DHCP and authentication servers normally in core networks, which causes longer latency than communication between clients and APs. Fig. 7(a) presents the CDF of the time until the first TCP ACK. On average, it takes 1.09 s in Bologna, 2.76 s in LA, 1.48 s in Macao, and 1.11 s in Paris. We note that these numbers are larger than the one (0.37 s) in open WiFi networks [3]. This is due to the fact that provider-managed WiFi networks require clients to interact with the authentication and DHCP server located in core networks, which leads to lengthened process. Nevertheless, the time to obtain TCP connectivity only counts for a very small part of the entire association (10%-18%, Fig. 8(b)), meaning that, for more than the 80% of the time that a vehicle is associated with an AP, it is possible to transfer data.

Takeaway:
The time spent for establishing end-to-end Internet connectivity in provider-managed networks is larger than the one in open WiFi networks because of the more complicated and lengthened interactions with the authentication and DHCP server in core networks. Therefore, optimizations, such as adopting authentication methods for faster handoffs [56,57] and granting extended DHCP leases to clients to retain its IP address, may reduce this time. Nonetheless, on average, this overhead only counts for a small part (10%-18%) of the whole duration of an association.

Connectivity duration and holes
Link-layer connectivity duration: Fig. 7(b) shows the CCDF of the link-layer connectivity duration. Median values are 9.22 s in Bologna, 17.29 s in LA, 7.99 s in Macao, and 9.04 s in Paris. The distributions are heavy-tailed, with a few long-lasting associations due to traffic lights and traffic jams, typical of urban mobility.   Fig. 9(a) depicts the CCDF of the IP connectivity duration. As for the link-layer, also these are heavy-tailed. In Bologna, LA, and Macao, both mean and median IP connectivity duration are slightly longer than the ones at link-layer. This is due to the exclusion of failed IP acquisitions (Table 3), likely to have shortened link-layer connectivity duration.

TCP connectivity duration:
The CCDF of the TCP connectivity duration is reported by Fig. 9(b). The mean and median values of the TCP connectivity duration are slightly higher than the ones of the IP connectivity duration due to the exclusion of associations unable to establish TCP connectivity, which tend to have shorter connectivity duration.
Link-layer connectivity holes: Due to the limited coverage of the existing urban WiFi deployments, there are gaps between successive associations. The CDF of the duration of the link-layer connectivity holes ( Fig. 10(a)) reflects the frequency at which vehicles encounter APs, denoting their density in the region. Both in Bologna and in Paris, the AP density is capillary, with a median inter-arrival time between two consecutive associations of 3.69 s and 2.13 s, respectively. On the other hand, APs in LA and Macao are rarer, with longer median interarrival time (8.64 s and 27.31 s). Since in Paris we only drove through densely populated neighborhoods, the mean is not too far from the median, with no sudden nor significant changes in the AP density across different locations. For all the other cities, the mean values are skewed from their median by a factor of 4x, meaning the holes at the tail of the CDF are particularly long. This denotes how the AP distribution changes significantly across different regions in Bologna, LA, and Macao. The presence of a few extremely short holes (tens of milliseconds) is due to de-authentication packets sent by some APs to force the disassociation from them.

IP connectivity holes:
As not every association succeeds in acquiring the IP address (Table 3), we expect the IP connectivity holes duration to be enlarged by failed IP acquisitions. For Bologna, LA, and Macao, the mean IP connectivity holes duration (Fig. 10(b)) are just marginally longer than those of the link-layer connectivity holes duration. This is F. Yang et al. because only a small fraction of associations in Bologna, LA, and Macao did not acquire the IP. Though, in Paris, the mean duration of the IP connectivity holes is greater than that at the link-layer. This is due to the DHCP issue discussed in Section 5. Fig. 11(a) we observe how the duration of the TCP connectivity holes is slightly longer if compared to that of IP. This is because of the exclusion of the fraction of associations that failed to establish a TCP connection, i.e. 15.9% in Paris, 9.4% in Bologna, 5.9% in LA, and 6% in Macao. From our dataset, it is possible to conclude how, on any commute lasting more than a handful of minutes, vehicles are likely to encounter several usable APs to actually transmit data.

TCP connectivity holes: From
Takeaway: The connectivity offered by provider-managed WiFi networks for in-motion vehicles is generally similar to that provided by open WiFi networks [3,27]: vehicles can expect to offload data for tens of seconds via an encounter with a provider-managed AP, and, are likely to have several such encounters every few minutes.

Impact of vehicle speed, ISS, and frequency
Next, we study the factors that may affect V2I WiFi connectivity. Specifically, we analyze the impact of vehicle speed, ISS, and WiFi frequency on the duration of link-layer connectivity. In the interest of space, we do not present the impacts on the duration of L3/L4 connectivity, as they are similar to the link-layer connectivity's ones.

Average vehicle speed per association:
The first factor that we consider is the vehicle speed. Intuitively, higher speeds lead to shorter connectivity duration, as the vehicle leaves the area covered by APs quicker. Fig. 12 confirms the correlation between the vehicle speed and the link-layer connectivity duration. Initial signal strength: Now, we consider ISS. In the stationary case, choosing the AP with the highest ISS works well. However, due to the continuous changes of the clients' position caused by vehicular mobility, the ISS alone is not enough to infer the network performance. In all the cities, the ISS ranges from being very weak (−80 dBm) up to an excellent signal level (greater than −50 dBm) as shown in Fig. 11(b).
To understand whether is enough to use the ISS as the only metric to infer, a priori, the network performance, we plot the correlation between the ISS and the link-layer connectivity duration (Fig. 13). From the plots, we cannot evince any obvious pattern confirming how associations with higher ISS last longer when mobility is involved. Surprisingly, some associations with a higher ISS are shorter than those with a lower ISS. This may be due to the vehicle moving from one extremity to the other of the AP coverage when it senses a weak ISS; while the vehicle could be already leaving the middle of the AP coverage when it senses a strong ISS. Hence, more sophisticated AP selection strategies, based on not only ISS, are called for improving V2I WiFi performance.   . 13. Correlation between ISS and connectivity duration: associations are partitioned into 2.5 dBm bins according to their ISS. We draw the box-whisker plot as in Fig. 12.
denotes the Pearson's Correlation Coefficient.
WiFi frequency: The last factor we take into account is the frequency of the WiFi APs. Since Free has only 2.4 GHz APs available in Paris, we omit it. Table 4 reports the correlations between the APs frequency and the connectivity duration. Interestingly, from our results, the duration of the connectivity offered by 5 GHz APs is sometimes better or at least comparable to the one offered by 2.4 GHz APs. This is likely because 2.4 GHz band has fewer independent channels than 5 GHz  band, thus, leading to severer radio interference, which further causes bursty beacon losses and interrupts connectivity.
Takeaway: (1) The AP selection algorithm of stock WiFi client implementations, which solely relies on ISS, is not sufficient when it comes to vehicular mobility. Applying location-aware AP selection approaches based on GPS history [58] is a good direction, which is likely to achieve better performance as of today since the provider-managed WiFi APs are very likely more stable and predictable than open APs; (2) 5 GHz APs often offer longer connectivity than 2.4 GHz APs in the V2I context likely due to the less severe radio interference.

IP address roaming support
Lastly, we investigated how the IP address (the local IP of the vehicle) assigned by a provider-managed WiFi network changes across different APs during a continuous drive. Usually, the IP address roaming (the ability of a host to retain the same IP address when roaming across APs) is not supported when a WiFi client switches to another operator's WiFi network unless the operators have a particular agreement. Hence, we focus on the IP address roaming inside WiFi networks operated by the same provider. Specifically, we investigate: (1) Can a vehicle keep its IP address unchanged during a continuous drive? (2) If not, for how long can a vehicle keep the same IP address? Table 5 reports the data collected for every WiFi network. 9 used in our measurement campaign. The column IP duration reports the average time during which vehicles keep an IP address unchanged during a continuous drive. The IP duration values shown are formatted as average ± standard deviation From our results, as only two networks apparently support it, we could not find any strong evidence of provider-managed WiFi networks supporting, by default, IP address roaming. Hence, either applications or transport layer protocols should take care of it as, otherwise, switching AP may break the connections established by connection-oriented protocol like TCP.

Takeaway:
The IP address roaming in provider-managed WiFi networks is not a must implemented by operators by default. Therefore, vehicular application designers must bear the caveat in mind if they want to leverage provider-managed WiFi networks. That said, transport protocols like QUIC [35,36], Multipath QUIC [25,26], and Multipath TCP [24], which supports IP handover, thus, hiding the IP changes from applications, are good options for vehicular applications using provider-managed WiFi networks.

Transport performance analysis
In this section, we first present: (1) the average goodput a vehicle can experience from an association; (2) the amount of data that can be transmitted during a single association. These results in Section 7.1 demonstrate that today's provider-managed WiFi networks can provide decent performance for V2I communication. Then, in Section 7.2, we compare the results between different CCAs, and study the impact of flow number on TCP goodput. Finally, the impact of vehicle speed, ISS, and WiFi frequency is analyzed in Section 7.3.

Goodput and data volume
Here, we seek to understand the capabilities of today's providermanaged WiFi networks in the V2I context from a high-level point of view. Therefore, we do not distinguish between TCP sessions with different flow number and CCA. It is also noteworthy that applications also use various TCP configurations in reality.
Average TCP goodput: To support real world applications, a connection with decent goodput is fundamental. In Fig. 14 we plot the CCDF of the average goodput per association, for both upload and download. The results in Macao seems very promising: for every association able to establish TCP connections, the mean goodput is 13.36 Mbps in upload and 8.66 Mbps in download; with peaks up to 103.44 Mbps and 90.48 Mbps, respectively. Peak performances are likely to be achieved when vehicles, due to traffic jams or lights, stop at places with good APs. Further, while the results from LA and Bologna are also quite encouraging, TCP does not perform as well in Paris, with 90% of the associations providing less than 2 Mbps for both upload and download. Like in the other cities, also the CCDF of Paris is heavy-tailed, biased by the vehicle stops by good APs. Notice, the maximum average goodput both in upload and download is ∼14 Mbps.

Data volume:
To gauge clearer insights on the network capabilities in such a scenario, we consider the actual amount of data uploaded/downloaded per association. Fig. 15 shows the CCDF of the data volume transmitted during each association. Both in LA and Macao is possible to transmit a considerable amount of data during every association (the mean data volume downloaded per association is 45  The reasons for the discrepancies between Paris and the other cities could be multi-folds. Firstly, the AP density in Paris is considerably higher than in the other cities and, therefore, we could suffer from higher radio interference in Paris. Secondly, only 2.4 GHz APs are provided by Free. In general, 5 GHz APs offer better performance, as they have more independent channels. Lastly, the APs in Paris are shared between private customers and public users, with customers who are often prioritized by the providers. Besides, in the other cities, there are also dedicated APs, which are with better hardware and friendlier to public users. Considering the total driving hours and the downloaded and uploaded data volume, our results from Bologna, LA, and Macao confirm that vehicles are likely able to download or upload around 1 GB (1.23 GB in Bologna, 1.44 GB in LA, and 0.73 GB in Macao) per hour by using stock TCP implementations, while on-the-go. Furthermore, this figure could improve with more APs coming into operation, and with a more capillary diffusion of 802.11ax APs. Moreover, as TCP is known to be inefficient when it comes to intermittent connectivity, this could get even better by using novel, alternative, transport protocols, such as QUIC [35,36].
Takeaway: Compared with the numbers provided by open WiFi networks in the past [3,[27][28][29][30][31], the TCP goodput (∼1 GB/h) offered by provider-managed WiFi networks is an order of magnitude higher, which shows the great potential of offloading data from cellular networks for connected vehicles.

Impact of CCA and flow number
Next, we compare the average TCP goodput per association of different TCP configurations to investigate the impact of CCA and flow number. It is noteworthy that the following analysis is based on the data collected from Macao, as it has more data for us to draw the relationships in a statistically significant way. Fig. 16 shows the CCDF of average TCP goodput per association under different TCP configurations.
First, from Fig. 16, we observe that no obvious differences between BBR and CUBIC, despite the superiority of BBR in conventional scenarios reported by previous studies [37]. The most likely reason is that BBR underestimates the round-trip propagation time (RTprop) in such a dynamic environment, which leads to an inappropriate estimation of congestion window size, thus, counterbalancing the merits of BBR. We note that this phenomenon is also reported by a TCP measurement study in high-speed rail scenarios [59].
Another observation made from Fig. 16 is that multiple TCP flows often deliver better performance than a single TCP flow. The reasons are two folds: (1) uncongestional packet losses have a severer impact

Impact of vehicle speed, ISS, and frequency
Now, we consider how vehicle speed, ISS, and frequency would impact TCP goodput. As in the previous subsection, we conduct our analysis based on the data collected from Macao due to its' larger scale.
First, the correlation between average vehicle speed per association and average TCP goodput per association is drawn in Fig. 17. We notice that, unlike the correlation between vehicle speed and connectivity duration in Fig. 12, the TCP goodput is not strongly related to vehicle speed: for download and upload, the R between vehicle speed and TCP goodput is only −0.12 and −0.08 respectively. On the other hand, we also acknowledge that the maximum goodput achieved in each speed bin tends to be higher when the vehicle speed is lower. We note that our results may be limited to the fact that the vehicle speeds were relatively slow in Macao, 0∼35 km/h, due to the local regulations on driving speed in populated urban areas.
Then, we draw the correlation between ISS and average TCP goodput per association in Fig. 18. Similar to the correlation between ISS and connectivity duration in Fig. 13, we do not find any evidence indicating that stronger ISS leads to higher TCP goodput. The results again call for more sophisticated AP selection algorithms that consider more factors rather than just ISS.
Lastly, we investigate how different APs with different WiFi frequencies could perform. Table 6 summarizes the average goodput achieved from 5 GHz and 2.4 GHz APs in both upload and download scenarios. We can observe that 5 GHz APs provide higher TCP goodput than 2.4 GHz APs in the V2I context, which comes from the fact that the F. Yang et al. Fig. 18. Correlation between ISS and TCP goodput: associations are partitioned into 2.5 dBm bins according to their ISS. The box-whisker plot is drawn as in Fig. 12. denotes the Pearson's Correlation Coefficient. 5 GHz band has more independent channels, and, therefore, more chances to use 40 MHz channel and less radio interference than the 2.4 GHz band.
Takeaway: (1) TCP goodput is not correlated with ISS, which corroborates that ISS alone is not sufficient for the AP selection in the V2I scenario; (2) 5 GHz APs provide notably higher goodput than 2.4 GHz APs. Thus, for the operators who are willing to support V2I WiFi offloading, they may prioritize 5 GHz APs in their future WiFi deployment.

Discussion
While this work focuses on TCP due to its' predominance, we are aware that cutting-edge transport protocols may outperform TCP. QUIC [35,36] is already deployed by many companies [35,62,63] thanks to its' benefits in terms of 0-RTT connection establishment and better loss recovery mechanisms. Further, QUIC's connection migration mechanism enables connections to continue across different APs, even if IP roaming is not supported. We leave a study of how QUIC performs in our setup as future work.
As of today, given the WiFi promising bandwidth reported in our results, we can conclude V2I WiFi connectivity can benefit non-realtime bulk transfer applications. Yet, it is still not clear how applications requiring continuous Internet connectivity can benefit from intermittent, rapidly changing, V2I WiFi links. A possible direction is to develop applications on top of multi-path transport protocols [24][25][26], combining cellular and WiFi links. This would allow applications to dynamically adapt to network changes, leveraging cellular links for key urgent information (e.g. malfunctioning, etc.), whilst offloading over WiFi, saving the cost of cellular networks, otherwise. However, extra care is paramount while designing the multi-path scheduler [64], to avoid incurring additional Head-of-Line (HoL) blocking caused by injecting data into the ever-changing WiFi link, as it would impair application-perceived performance [33,[65][66][67].
Although the full-fledged 5G Standalone (SA) connectivity [68] is poised to enhance V2I communication performance, recent measurements [69] have shown that current deployments of 5G Non-standalone (NSA) services are still far from being satisfactory. Ultimately, we believe that in the transition to, or even in the world of the fullfledged 5G SA deployments, V2I WiFi offloading via prevalent providermanaged WiFi networks can complement 5G due to its' low-cost and performance.
Currently, the key industries of connected vehicles are also actively working on DSRC and C-V2X to provide network access for connected vehicles [70]. However, the applications that DSRC and C-V2X target are mostly real-time ones, such as sharing sensor data with other vehicles and roadside facilities in real-time to improve road safety. The non-real-time bulk transfer applications, e.g. infotainment, FOTA updates, and telemetry reports, still mainly rely on cellular networks, which put a lot of pressure on cellular infrastructures and add costs to users and car vendors. From this point of view, WiFi offloading is appealing because of the low price and decent bandwidth of WiFi networks. On the other side, WiFi networks can also complement DSRC and C-V2X for better application performance. For instance, WiFi offloading can be used for the control traffic in DSRC, in order to improve throughput [17].

Conclusion
In this paper, we revisit the opportunities of using WiFi offloading for V2I communication, and how this has changed over the last decade. Through an extensive measurement study across 4 cities located in 3 continents over 22 months, we confirm the feasibility of using providermanaged WiFi networks for V2I WiFi offloading, and, quantitatively analyze the transmission capability offered by such networks. Our data show that current provider-managed WiFi networks are much superior to open WiFi networks in the past for V2I WiFi offloading, especially when it comes to application goodput. Moreover, several implications on transport protocols and WiFi deployments are made from our measurement study. We hope that our work will shed light on the use of provider-managed WiFi networks for V2I WiFi offloading in the future.

Declaration of competing interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Furong Yang is currently a Ph.D. candidate at ICT/CAS. He is also in a joint doctoral program between the University of Chinese Academy of Sciences and Sorbonne University since 2018. His main research interests lie in TCP congestion control, multipath transport protocol, and Internet measurement. Suman Banerjee (Fellow IEEE/ACM) received the undergraduate degree from IIT Kanpur in computer science and engineering and was a gold medalist in his graduating class, and the MS and Ph.D. degrees from the University of Maryland. His Ph.D. dissertation was the university's nomination for the ACM Doctoral Dissertation Award. He is a professor in computer sciences with UW-Madison where he is the founding director of the WiNGS laboratory which broadly focuses on research in wireless and mobile networking systems. While at Wisconsin, he received the CAREER award from the US National Science Foundation and the inaugural Rockstar Award from ACM SIGMOBILE for early career achievements and contributions in his field. He has authored more than 100 technical papers in leading journals and conferences in the field, including the ACM/IEEE Transactions on Networking, the ACM/IEEE Transactions on Mobile Computing, ACM Sigcomm, ACM MobiCom, IEEE Infocom, ACM MobiSys, ACM CoNEXT, ACM IMC, IEEE Dyspan, and more. It also includes various award papers from conferences such as ACM MobiCom, ACM CoNEXT, and IEEE Dyspan. He served as the chair of ACM SIGMOBILE between 2013 and 2017.