Session 8, Paper 2: Wi-Fi Goes to Town: Rapid Picocell Switching for Wireless Transit Networks

Authors: Zhenyu Song, Longfei Shangguan and Kyle Jamieson
(Princeton University)

Presenter: Zhenyu Song

In the near future, driverless cars will transform the current commute for many into a time when other activities such as audio and video teleconferences, VR online gaming  can be performed. However in order to achieve this, it requires high-capacity networks to operate along transportation corridors and the Wi-Fi Goes to Town service is a potential solution to this problem.

In the past few years, capacity gains in cellular wireless network operations have been attributed to decreasing the size of each cell the access point (AP) covers although this  reduces the range covered by the cell. This work takes advantages of this concept  and two additional trends that have arisen in AP capabilities and pricing. First of all commodity Wi-Fi APs can be used to extract detailed channel measurements allowing prediction of the best AP to suit  a client as it moves and secondly,  the availability of low cost Wi-Fi chipsets (<$5) makes deployment of high density Wi-Fi AP installations cost-feasible.

Wi-Fi Goes to Town (WFGTT)  is the first Wi-Fi based roadside hotspot network designed to operate at vehicular speeds with meter-sized picocells. The design consists of many picocells (forming an AP array) along a busy urban transit corridor with each cell covering a few meters. However two challenges faced by users as they drive  past each AP are fading (in seconds) due to increased distance as well as fading (in milliseconds) due to alternating constructive and destructive multipath propagation. Due to this phenomenon, the authors coined the phrase vehicular picocell regime to refer to the combination of AP diversity, vehicular client mobility and meter-level AP cell size.

Resolving these issues requires fast switching (at a millisecond level) between APs with the best channel capacity and a solution that gives TCP the illusion that the network never changes. Their WFGTT solution is designed to operate efficiently in the vehicular picocell regime via a nearby controller which exercises tight control of the AP array. Delivery decisions to the vehicle are made by the serving APs at millisecond-level granularities and exploit the path diversity present in roadside networks.

Their solution addresses the following questions:
1. Who maintains state?
The controller maintains the state and makes switching decisions between the APs. This makes the    stack transparent to the client end user and enables fast handover since the controller can access global information easier.

2. When to switch APs?
The authors design an AP selection algorithm based on an Effective SNR window value and use it to select the AP with the largest median value every 10ms.

3. How to switch between APs?
Whenever a client connects to an AP, this connection information is propagated to all other APs so that when a switch is required, the client can move to any AP.

In the case of downlink  traffic, as a user travels along the road, each AP receives all the packets destined for the user from the controller and waits for communication from the controller. The controller also adds a packet ID to each packet it sends downstream to allow APs to track which packets have been sent to the user. Once the controller has made a switching decision, it informs the current AP serving the user to stop forwarding data to the user and also gives the ID of the next AP that should continue delivering the packets. The current AP stops sending packets, sends the ID of the last packet it sent to the next serving AP and requests this new AP to start sending the next data to the user. This new serving AP then sends an ACK back to the controller and begins forwarding data to the user.

Once delivery of data from an AP to the user is successful, that AP directs the others to discard their copies of the packet resolving the  pending packet problem and also the packet queuing problem at the APs is resolved by sharing the block acknowledgement state between participating APs.

In the case of uplink traffic, all APs have the same bussid so any AP can receive the packet and forward to the controller which removes duplicates from the same client before forwarding the packet upstream.

The authors implemented their system in an eight AP roadside network and performed tests with mobile clients up to 35mph comparing the performance of WFGTT with a performance tuned version of IEEE 802.11r and 802.11k.  When compared to the base line protocol, results showed that Wi-Fi goes to Town can achieve 2.4 - 4.7x TCP throughput improvement and a 2.6 - 4.0x improvement in UDP download performance with vehicle speed ranges from 5 - 25mph and 2.4 - 2.6x improvement in TCP and UDP download performance in a multi-client scenario.

Questions and Answers

1. Question: Why did you use a larger  router? Are you using different channels between the APs and is the IP address fixed?

Answer: We used a TP link router because it was easy to use as a prototype, however for production, we are investigating use of other types. Our solution uses 1 channel till it is saturated but we can replicated the solution independently on different channels. The IP address is fixed.

2. Question: In your solution, the association table and client data is  propagated between all APs. However this may not be feasible for large networks so h ow does your solution address this ?

Answer: Our algorithm can be modified and be made scalable so that the data is only propagated  within a small range of APs depending on  the clients predicted location in the near future. 

3. Question: Did you  perform any experiments to verify impact of distance between the different APs?

Answer: Yes, we performed experiments changing distance between APs and results are comparable in all cases.

4. Question: The controller performs many operations such as synchronization and switching and is a critical component of the solution. Isn't the 10ms time frame too small for switching and frequently using additional resources at the controller?

 Answer: The controller is connected to the external network via a wired high bandwidth link and also has sufficient resources to handle the switching every 10ms. 

5. Question: Your current experiments are for vehicles operating at lower speeds(0 - 35mph), how does your solution perform for higher speed vehicles?

Answer: The speed was only limited by the environment because the lab overlooks a road with a low speed limit. Future work includes moving the test bed to a high speed road an increase of the number of APs.