IEEE 802.11 Link-Layer Forwarding For Smooth Handoff

IEEE 802.11 Link-Layer Forwarding For Smooth Handoff Marc Portolés

Zhun Zhong

Sunghyun Choi

Chun-Ting Chou

Universitat Politècnica de Catalunya [email protected]

Philips Research USA [email protected]

Seoul National University [email protected]

University of Michigan [email protected]

Abstract- In this paper, we present a link-layer packet forwarding scheme to reduce packet losses during a handoff in IEEE 802.11 WLAN. Through a novel scheme utilizing buffer and image queues in the device driver, the scheme is able to recover most packets that would otherwise be lost during the handoff, including those held in the network interface card. Our experimental results from a test-bed show that the proposed scheme can eliminate or significantly reduce the packet losses in UDP traffic, and help preserve throughput for TCP traffic when the retransmission time out (RTO) is large. To achieve the maximum benefit, we propose to apply the forwarding scheme adaptively depending on the traffic type. Keywords – IEEE 802.11, WLAN, IAPP, handoff, device driver, TCP, UDP

I. INTRODUCTION In recent years, IEEE 802.11 Wireless LAN [1] has gained a prevailing position in the market among a group of emerging technologies for the (indoor) broadband wireless access. To continue its success, the 802.11 WLAN needs to keep addressing emerging challenges, such as security issue, quality of service (QoS), and seamless mobility support, to name a few. Seamless mobility experience has always been a design goal for mobile wireless networks. To address the mobility issue, IEEE 802.11 defines services to support handoff in its 1999 version of the standard [1]. Furthermore, a task group, called Task Group F (TGf), in the IEEE 802.11 Working Group is working on an extension to the original standard, known as the inter-access point protocol (IAPP), to facilitate the handoff in IEEE 802.11 WLAN [2]. The handoff in IEEE 802.11 WLAN is by its nature a hard handoff as a station has to stop the communication with the old access point (AP) at the beginning of the handoff process and cannot resume communication with the new AP until the handoff completes. As a result, the station is likely to miss some packets that arrive during the handoff process. One way to recover these lost packets is to request the old AP to buffer packets addressed to the handoff station, and forward these packets to the new AP after the handoff process is completed. A similar buffer-and-forward idea has been exploited in the past in the context of the Mobile IP [3]. Using the buffer-and-forwarding at the network layer (i.e., the IP layer), however, these approaches ignore some packets held in lower layers, and respond slowly to the handoff event, as will be discussed later in details. Moreover, note that a handoff within a sub-network does not involve the network layer mobility support. In this paper, we propose a packet buffer-and-forward scheme at the linklayer, which not only recovers all the packets, but also reacts faster to the handoff event.

Note that reducing packet losses at the link-layer does not automatically translate into a better higher-layer experience. Depending on the transport layer protocols employed, the higher layer may react to the reduced packet losses in different manners. To study the effect of the proposed link-layer packet forwarding perceived by the end user (i.e., at the application layer), we have experimented the proposed scheme on our real implementation test-bed, using both UDP (for a video streaming) and TCP (for a file transfer) applications. The experimental results show that the proposed scheme can eliminate or significantly reduce the packet drops for UDP applications. On the other hand, for TCP applications, the scheme works well when the retransmission time out (RTO) is larger than the handoff delay, but it introduces a negative effect when the RTO is smaller than the handoff delay. Our observation suggests that, in order to maximize the benefit, the link-layer packet forwarding scheme should be applied in an adaptive manner depending on the type of traffic. The rest of this paper is organized as follows: We first introduce the handoff process as defined in IEEE 802.11 standard in Section II. Next, in Section III, we present our proposed link-layer buffer-and-forward scheme in detail to reduce the packet losses during a handoff process. The testbed and the experimental results are presented and discussed in Section IV. Finally, we conclude the paper in Section V. II. HANDOFF IN IEEE 802.11 The basic building block of an IEEE 802.11 WLAN deployment is a basic service set (BSS), which is composed of an access point (AP) and multiple stations (STAs) associated with the AP. 1 Multiple BSSs can be connected by the distribution system (DS) to form an extended service set (ESS). The standard does not define how to implement the DS. However, the DS is typically realized by connecting multiple APs via Ethernet cables and switches. The IEEE 802.11 WLAN supports three types of station mobility: (1) No-transition (static or intra-BSS movement), (2) BSS-transition, and (3) ESS-transition. In this paper, we study the handoff that refers to the BSS-transition, defined as the movement of a STA from one BSS in one ESS to another BSS within the same ESS. The BSS-transition is supported by the reassociation service. Typically, a handoff process starts with a STA moving away from the AP with which it is currently associated and experiencing of the signal quality degradation. The STA then scans all the 1

A type of BSS called “independent BSS” is composed of only non-AP STAs, but this type of BSS is out of our scope.

possible channels, trying to locate another AP in the same ESS with a better link quality. Should such an AP be located, the STA proceeds with authentication and reassociation processes to join the BSS of the new AP. A. Emerging IEEE 802.11f IAPP The IEEE 802.11 Working Group is currently close to releasing a recommended practice, called IEEE 802.11f, for the inter-access point protocol (IAPP), as an extension to the original standard [2]. This extension “specifies information to be exchanged between APs among themselves and higher layers to support 802.11 DS functions.” This standard suggests how to implement the DS with a primary goal to facilitate the handoff. The protocol provides a mechanism for APs to exchange STA information prior to the handoff, allowing preauthentication, thus reducing handoff delay. After the handoff process, the protocol defines a layer-2 update frame to be broadcasted by the new AP to all the layer-2 devices within the same subnet. Sent with the newly associated STA as the source, the layer-2 update frame will update the forwarding table in all the Medium Access Control (MAC) bridges and layer-2 switches so that future packets addressed to the STA will be forwarded to the new AP.

Finally and the most importantly, when a handoff is performed within a subnet as we consider in this paper, the network layer is not involved with the handoff process. Therefore, the network-layer forwarding scheme cannot improve any performance in such cases. Having observed these limitations in the network-layer forwarding scheme, we propose a link-layer forwarding scheme that will recover more packets to forward, and will know the occurrence of a handoff quicker. III. LINK-LAYER FORWARDING SCHEME In this section, we present our proposed link-layer forwarding scheme, which, as shown in Figure 1, consists of two components: the store/forwarding unit, and the handoff detection unit, both implemented in the device driver of the AP. Network layer

Store & Forward DRIVER Handoff Detection

B. Problem Statement Despite the effort to reduce the handoff delay, the scanning process, authentication process (if applicable), and the reassociation process take hundreds of milliseconds to complete. Our measurement on off-the-shelf 802.11b products shows the number ranges from 200 ms to over 600 ms, during which the STA is deprived of data communication with both APs. Before a handoff is completed, packets addressed to the STA will still arrive to the old AP, which, however, can no longer reach the STA. As a result, some packets will be lost due to the handoff disruption. Our approach is to reduce the number of packet losses due to handoff by requesting the old AP to buffer packets during handoff, and forward packets to the new AP after the handoff. Similar buffer-and-forward idea has been exploited at the network layer, i.e., mobile IP, which has the following three limitations. First, the network-layer forwarding scheme buffers packets at the network layer, assuming that every packet sent down to the layer-2 (or the corresponding device driver) is already, or will be, delivered to the STA. Unfortunately, in most cases this assumption is not valid, as many network interface driver and MAC controller implementations have queues built in to hold certain number of packets. Therefore, the network-layer forwarding scheme cannot forward all the packets that should be forwarded. Second, the network-layer forwarding scheme relies on the network layer notification to know the occurrence of the handoff. The sooner the old AP knows about the handoff event, the sooner it can forward the buffered packets to the new AP, thus the quicker the STA will get the forwarded packets. The network-layer notification, however, is not the fastest way by which the old AP can learn about the occurrence of the handoff. Lower layer knows earlier.

DEVICE

Figure 1. Link-layer packet forwarding scheme A. Link-layer forwarding In our link-layer forwarding scheme, the packet buffering and forwarding are performed in the device driver level, as shown in Figure 2. The driver maintains a queue of each handoff station, holding packets for forwarding. Upon signalling received at the link layer, the old AP forwards all the buffered packets destined to the handoff station via the DS. Other packets not yet sent down to the driver (i.e., held in the higher layer) will eventually enter the driver, and then be forwarded to the new AP directly. Compared with the network-layer forwarding scheme, this scheme enables the recovery of the packets held in the driver during a handoff. Network layer Forwarded to new AP after handoff buffer Wireless interface driver Wireless interface card

Figure 2. Driver buffer and forwarding However, the underling assumption of the driver bufferand-forward scheme is that every packet accepted by the

network interface card is delivered to the STA. Again, this assumption is valid only if the network interface card immediately delivers every packet forwarded by the driver. The fact, however, almost all network interface cards have internal queues built in to hold several packets, as illustrated by Figure 3. Network layer Forwarded to new AP after handoff

buffer

Wireless interface driver queue Wireless interface card

Figure 3. Queue in the interface card It is clearly shown in Figure 3 that the forwarding scheme discussed so far cannot recover those packets, which were already sent through the driver to the card, but could not be transmitted successfully by the card during a handoff. To recover such packets held in the internal card queue, we propose to maintain an image queue in the driver to mirror the queue in the card. For every packet sent to the card, we keep a copy in the driver. Whenever the card delivers a packet, it reports to the driver and the driver deletes the packet from its image queue. By this means, the driver keeps track of the status of the queue in the card by storing copies of the packets currently in the card queue. This is illustrated by Figure 4. Network layer Forwarded to new AP after handoff buffer Wireless interface driver

Image queue queue

Wireless interface card

Figure 4. Driver image queue Once the new AP signals for a STA’s handoff completion, the old AP will forward not only those packets held in the driver buffer, but also those packets held in the image queue, as none of them has been delivered to the STA yet.

B. Handoff detection There are two aspects in handoff detection: to know when handoff is about to happen and to know when handoff is completed. For a certain period of time just before a handoff, typically the link quality can become so bad that the AP cannot successfully send packet to the STA even after reaching the retransmission limit. Instead of discarding such packets, we propose to recycle them, and forward them to the new AP after a handoff. We use the consecutive packet transmission failure as an indicator to prepare for a handoff by starting to buffer unsuccessfully transmitted packets. In this way, we are able to recover not only the packet lost during a handoff but also some of the packets lost before the handoff. Having buffered the packets for the handoff STA, the old AP will eventually need to know when to start forwarding. As defined in IEEE 802.11f, upon the reassociation of a handoff STA, the new AP will send out a layer-2 update frame before any further actions. Since the layer-2 update frame is a layer-2 broadcast frame, the old AP (as a layer-2 device itself) will receive the frame as well. Next, the wireless interface driver of the old AP will receive this broadcast frame. By checking the source address of this frame, the old AP can identify that the STA was once in its BSS. The reception of this layer-2 update frame, therefore, signals that the STA has just handed off to a new AP. To forward packets to the new AP, the old AP can simply send the packets to the DS without knowing the identity of the new AP. The new AP should get all the packets, as all the layer-2 devices have been updated with the new routing table, and hence know where to forward packets addressed to the destination STA. IV. EXPERIMENTAL RESULTS A. Test-Bed The test-bed used for our experiments is shown in Figure 5. AP 1 and AP 2 are two laptops running Linux, each equipped with an Intersil Prism2-based 802.11 card and a 3COM Ethernet card (both in the PCMCIA form). With the HostAP driver [4] installed for the Prism2 cards and the bridge module configured in the Linux kernel, these two laptops function just like off-the-shelf AP boxes. We have modified the HostAP driver to include the layer-2 update frame, the driver image queue, and the buffering and forwarding scheme discussed in the previous section. An Ethernet network serves as the DS, connecting both APs as well as the content servers. A 100 Mbps Ethernet switch is used to interconnect multiple nodes at the link layer. Two local servers (labelled as FTP server 1 and video server) are connected directly to the LAN, and the third server (labelled as FTP server 2) is a public FTP server in the Internet, connected to the system via a router. The two APs are placed properly so that when the station moves away from one AP towards the other AP, the handoff occurs at a certain point. The mobile STA is also a laptop with an 802.11 interface, and runs the FTP and video streaming clients.

Global network Server + Gateway FTP server 1

Video server

Switch

FTP server 2

AP 1

AP 2

packets are queued up in the buffer located in the old AP. As the buffer size is limited, some packets can be dropped due to the buffer overflow. Therefore, these packet drops could be eliminated if we had allocated more memory space to our buffer. As far as the perceptive visual quality is concerned, whereas there were annoying artefacts resulted from packet losses without forwarding, the video presented no perceived disruption during a handoff with our forwarding scheme employed. 2) TCP traffic

STA

Figure 5. Test-bed B. Results 1) UDP traffic To test the effectiveness of our link-layer forwarding scheme on UDP traffic, we first conducted the handoff experiments using a video streaming application. A standard Darwin streaming server [6] was used for the video server. We did experiments at three different streaming bit rates, i.e., 1.0, 1.5, and 2.0 Mbps. As illustrated in Figure 6, experimental results show that in all scenarios our forwarding scheme significantly reduced the number of packet losses during a handoff. Especially, at 1.0 Mbps, our forwarding scheme totally eliminated packet loss experienced at the client during a handoff, compared with over 50 packets lost without forwarding. As the streaming bit rate increased to 2.0 Mpbs, packet loss increased to about 100 without forwarding, but our forwarding scheme reduced the loss to less than 5 packets.

To test the effectiveness of our link-layer forwarding scheme on TCP traffic, we conducted handoff experiments using an FTP application. Unlike UDP where a packet loss is directly reflected at the client as a loss, TCP has the retransmission mechanism to ensure all the packets eventually get delivered to the client. Therefore, instead of measuring packet loss as we did for the UDP application, we measured the throughput experienced at the client for the TCP traffic. We have observed very interesting results, some of which are quite counter intuitive. Figure 7 shows the throughput measurement in the case without packet forwarding when the STA downloads a large file from FTP server 1. Due to the packet losses, TCP experienced retransmission and the congestion control function in the server reduced the transmission window. Accordingly, a throughput drop was observed during the handoff as shown in the figure.

Figure 7. TCP throughput without forwarding

Figure 6. Packet loss result for UDP traffic Note that the application needs a certain level of buffering to accommodate some of packets that may be delayed due to the network congestion. In our case, the video stream application has an initial buffer of 2 seconds, large enough to cover the latency of the handoff. Therefore, the packet drops observed with the forwarding scheme at high bit rates are not likely caused by the receiver discarding the late packets. Rather, we found that these packets were dropped in the old AP due to the buffer overflow. That is, during a handoff, a transient disconnection happens, and the

Figure 8. TCP throughput with forwarding

One would, however, expect that the throughput of TCP traffic is improved when the packet forwarding scheme is employed, as most of the lost packets would be recovered by the forwarding process. Different from such an expectation, our experiment using the local FTP server showed that the throughput suffered even more during handoff with packet forwarding, as shown in Figure 8. The further degradation of TCP throughput is turned out to be due to the short TCP retransmission time out (RTO). In this experiment scenario, the client and server were connected via the same local area network in which the RTO is just a couple of hundred milliseconds, comparable or even shorter than the handoff delay. As a result, the RTO expires before the packets are forwarded, resulting in the server retransmission of the lost packets. Eventually, the forwarded packets arrive, and invoke duplicated ACKs, which in turn seduced the server to apply another round of congestion control and further reduce the transmission window. This replication of packets is illustrated in Figure 9.

that, when the RTO is large enough compared with the handoff delay, all the packet losses are recovered, thus no retransmission is invoked. One should be careful when applying the packet forwarding scheme to TCP traffic, as the effectiveness of packet forwarding depends very much on the relative duration of TCP RTO to the handoff delay. While packet forwarding helps by avoiding retransmission in the case where RTO is larger than the handoff delay, it does have a negative impact on TCP throughput when the RTO is smaller than the handoff delay. V. CONCLUSIONS In this paper, we have presented a link-layer packet forwarding scheme to reduce packet losses during a handoff process in the IEEE 802.11 WLAN. Using buffering and image queues in the device driver, the scheme is able to recover the most packets that would have been lost otherwise, including those held in the network interface card. Experimental results showed that our link-layer packet forwarding scheme can recover almost all packet loss during a handoff. For UDP traffic, this translates directly to less (or no) packet loss and much better perceived application-level quality. For TCP traffic, however, the effectiveness of the scheme depends very much on the relative duration of TCP RTO and the handoff delay. The forwarding works well in the case when TCP RTO is larger than the handoff delay. We propose two solutions to maximize the benefit of the packet forwarding scheme: (a) One can apply the forwarding scheme adaptively, i.e., for UDP traffic, but not for TCP traffic. (b) Otherwise, one should implement a filtering functionality in the new AP to prevent the duplicate packets and duplicate ACKs from unnecessarily invoking retransmission.

Figure 9. Duplicated packets for small RTO

REFERENCES [1] IEEE Std. 802.11-1999, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Reference number ISO/IEC 8802-11:1999(E), IEEE Std 802.11, 1999 edition, 1999. [2] IEEE 802.11f/D5.0, Draft Recommended Practice for MultiVendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution System Supporting IEEE 802.11 Operation, January 2003. [3] C. Perkins and K.Y. Wang, “Optimized Smooth Handoffs in th Mobile IP,” in Proc of the 4 IEEE Symposium on Computers and Communications (ISCC '99), June 1999. [4] Jouni Malinen, Host AP driver for Intersil Prism2/2.5/3, http://hostap.epitest.fi/. [5] Apple’s open source project, Darwin Streaming Server, http://developer.apple.com/darwin/projects/streaming/.

Figure 10. No duplicated packets for large RTO To justify the rationale, we did another experiment using a FTP server in the Internet, which gave a RTO about 2 second. The experiment result shown in Figure 10 verifies