2824
IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 5, NO. 10, OCTOBER 2006
A Receiver-based Vertical Handover Mechanism for TCP Congestion Control Yuci Gou, David A. J. Pearce, Member, IEEE, and Paul D. Mitchell, Member, IEEE Abstract— We propose and evaluate a vertical handover mechanism for TCP, based on receiver Bandwidth Delay Product (BDP) measurement and congestion control using the receiver’s advertised window. It addresses the negative impact of abrupt changes in link capacity and latency on TCP performance during make-before-break vertical handover in heterogeneous networks, enabling TCP to seamlessly adapt to new conditions. It resolves the problem of buffer overflow in a low capacity network on handover from a high capacity network, and the under-utilisation problem on handover in the reverse direction. All modifications are restricted to the mobile device, and the proposed technique is fully interoperable with existing TCP and Mobile IP infrastructure. It maintains end-to-end semantics, supports IP security, and can be easily deployed. Index Terms— vertical handover, receiver-based, TCP, Mobile IP, congestion control, BDP measurement.
I. I NTRODUCTION HE demand for affordable, high capacity wireless Internet access from mobile users is increasing, and is being addressed by increases in the data rates available to cellular phone users through technologies such as the packet-based enhancements to second-generation mobile systems including the General Packet Radio Service (GPRS) and third generation wireless networks (3G). Another access technology is provided by Wireless Local Area Network (WLAN) systems. Data rates provided by WLANs can be two orders of magnitude higher than those available from a GPRS network, and the link latency is typically much lower, but they are designed for short-range communication and therefore only represent an effective alternative to GPRS networks in so called ‘hot spots’, such as airports, train stations, cafés and hotels. Many cellular service providers are now considering or implementing an integration of GPRS or 3G networks with WLAN, using dual-mode mobile devices to enable high-performance, highquality and high-speed services, whilst maintaining the cellular networks’ capability for extended geographic coverage. Achieving seamless handover from one network to another is a key challenge if effective use is to be made of multistandard capability within a mobile device. Two primary stages are generally involved in the handover process. The first is handover at the data-link layer to enable communication through a different access point. If the new access point is within another IP subnet, then a second handover is required at the network layer, to enable use of an IP address recognised as
T
Manuscript received August 25, 2004; revised April 19, 2005 and September 29, 2005; accepted October 9, 2005. The associate editor coordinating the review of this paper and approving it for publication was M. Zorzi. The authors are with Department of Electronics, University of York, Heslington, York, Yorkshire, YO10 5DD, United Kingdom (e-mail: {dajp1, pdm106}@ohm.york.ac.uk,
[email protected]). Digital Object Identifier 10.1109/TWC.2006.04583.
belonging to the new network. Mobile IP provides a standardsbased approach to address internetworking handover, and has been widely deployed [1], [2]. Handover can be conveniently classified into two categories: horizontal handover where the handover is between two similar systems; and vertical handover where the handover is between two different systems (for example between a WLAN and a cellular network). With vertical handover, there is often a significant disparity in the supported data rates and latencies of the two networks involved in the handover, usually much greater than that associated with horizontal handover. In horizontal handover, the network layer handover is typically performed after a change of wireless access point (i.e. following completion of the data-link layer handover). By contrast, during vertical handover in overlay networks, the network layer handover is typically decoupled from the datalink layer handover and can be performed independently, since the mobile node is able to use both of its interfaces to send and receive packets simultaneously. As a result, techniques such as simultaneous bindings [3], necessitated by the timing ambiguity in horizontal handover, are not required for vertical handover. The Transmission Control Protocol (TCP) is the dominant transport layer protocol in use in the Internet, used by almost all applications including file transfer, web browsing, e-mail, and streaming audio and video. TCP uses a sliding-window based congestion control scheme, with the size of the transmit window being the lesser of the receiver’s advertised window awnd and the sender’s congestion window cwnd. The size of cwnd is determined by well-known algorithms designed to limit the effects of congestion in the Internet, including slow start, fast retransmit, and fast recovery [4]. There are several versions of these schemes in current use in the Internet, here we consider three typical variants: SACK, FACK and NewReno [5]–[7]. In this paper, we propose and evaluate a receiver-based vertical handover mechanism for TCP congestion control that addresses the impact of vertical handover between heterogeneous networks with disparate data rates and Bandwidth Delay Products (BDP), and eliminates the observed performance degradation. The remainder of this paper is organised as follows: in section II we describe the scenario of interest in detail, highlighting the key issues associated with the vertical handover process; in section III we discuss the relationship of this work to previous work in this area; in section IV we describe our proposed mechanism; the simulation environment is detailed in section V and a performance evaluation is given in section VI. We conclude the paper in section VII.
c 2006 IEEE 1536-1276/06$20.00
GOU et al.: A RECEIVER-BASED VERTICAL HANDOVER MECHANISM FOR TCP CONGESTION CONTROL
Internet GGSN: FA
Access Router: Foreign Agent(FA)
Allocation per-mobile
Home Agent SGSN
Access Point
FTP Server: Correspondent Node
Ha
BSC
nd
ove
r
WLAN Hot Spot Mobile Node
Fig. 1.
GPRS Base Station
Loose coupling WLAN-GPRS integration.
II. S CENARIO D ESCRIPTION The integration of WLAN and GPRS is generally achieved using one of two architectures: loose coupling or tight coupling [8]. The significant difference between these architectures is in the intermediate routers, and since our scheme does not involve any difference in the behaviour of these routers, we consider only loose coupling as a representative case. The scenario of interest is depicted in Fig. 1, which illustrates a typical make-before-break (MBB) vertical handover between heterogeneous networks consisting of a WLAN hotspot overlaid with cellular coverage. During MBB handover, the Mobile Node (MN) makes the new connection before the old one is broken, so that the MN can communicate simultaneously with both the old and new access routers during handover [9]. The Correspondent Node (CN) represents the TCP sender located somewhere in the Internet, with the MN designated as the receiver. The MN uses a Care-of-Address (CoA) assigned by the local Foreign Agent (FA), or the Gateway GPRS Service Node (GGSN). All TCP packets from the CN travel via the MN’s Home Agent (HA). TCP packets destined for the MN are tunnelled from the HA to the current FA, and returning acknowledgements (ACKs) from the MN are sent to the CN. When the MN roams between a WLAN and a GPRS network, vertical handover is performed and TCP packets arriving at the MN are switched between the WLAN Access Point (AP) and the GPRS Base Station (BS). Each direction of handover presents a different problem for TCP that can produce a noticeable disruption to the user. We will first consider the problem of buffer overflow on handover from a high-BDP network (i.e. WLAN, in our study) to a low-BDP network (i.e. GPRS, in our study), and then the problem of under-utilisation on handover from a low bandwidth network (GPRS) to a higher bandwidth network (WLAN). We assume that the wireless link in the GPRS network is the bottleneck link, which is the most usual situation [10]. On handover from WLAN to GPRS, TCP packets are diverted to the GPRS network and will form a bottleneck queue due to the significant drop in the data rate. Buffering is available at multiple protocol layers in GPRS, but when reliable Radio Link Control (RLC) and unreliable Logical Link Control (LLC) modes are used, the only buffers enabled
2825
are at the Serving GPRS Support Node (SGSN) [11]. The SGSN is likely to undergo buffer overflow when a transmit window having been set up for WLAN is larger than the buffer allocation per mobile in GPRS. For example, the allocation per-mobile of the UK Vodafone GPRS network has recently been configured to about 30KB [12]. This is adequate for most purposes since 30KB is greater than the BDP of the GPRS downlink (typically less than 5KB [11]). However, the BDP of WLAN is likely to be much greater than 30KB, as with an end-to-end latency of 120ms and 5.5Mbps data rate the BDP is more than 80KB (note that the end-to-end one-way latency is assumed here to be higher than the wireless link latency by 60 milliseconds to account for the length of the Internet path). Prior to handover from GPRS to WLAN, there is usually an excess queue in the GPRS system [10], before the bottleneck wireless link. The primary issue to address is significant underutilisation of the WLAN capacity during and immediately after handover. It is shown later that when the MN moves from the low-speed cellular network to the high-speed WLAN, the slowly draining bottleneck queue at the SGSN severely inhibits TCP from quickly increasing the transmission rate to use the capacity of WLAN. If the WLAN link is only available for a short period of time, the WLAN capacity is never fully utilised. III. R ELATED W ORK Kim proposes a variation on Goff’s Freeze-TCP [13] scheme to deal with the potential disparity in heterogeneous mobile networks [14]. The receiver in the original Freeze-TCP scheme advertises a window size of zero to suspend operation during handover to prevent packet loss, and this modification requires the TCP sender to enter a slow start phase following handover, which permits cwnd to increase faster than it would in congestion avoidance (exponentially instead of linearly). The TCP sender can therefore increase its rate faster than with conventional Freeze-TCP. In addition to unnecessary suspension of the TCP connection in overlay networks, a key drawback of this approach is the need for modifications to the TCP protocol at both the sender and receiver. This does not meet the recommendation of the Mobile Network Computer Reference Specification (MNCRS) consortium, who state that changes to protocols should be restricted to devices under MNCRS control, i.e. mobile devices and the base station or proxy, in order to be practical [15]. Gurtov suggests that the buffer of all links should be configured to the maximum BDP of any link, to deal with packet losses occurring when there is a rapid change in the BDP [16]. However, this relies on the network operator knowing the maximum BDP of all the links, which may be impractical, and results in links with a low BDP suffering from excess queuing that makes interactive applications less responsive, artificially inflates the round-trip time so that loss recovery is delayed when timeouts occur, and unnecessarily delivers packets to the receiver when a user aborts a data transfer [12], [17]. To address the under-utilisation problem on handover from the cellular network to WLAN caused by excess queuing, Chakravorty et al propose a buffer management scheme using
2826
IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 5, NO. 10, OCTOBER 2006
MN
AR: FA
GGSN: FA
HA
FTP Server
ADs ADs The copy of the last ACK with awnd set to the maximum BDP for GPR S
ta1 Td
tr1
Tack
ta2
Req
Treg
tr2 ta3
(tr2, t a3)
Reply
From WLAN to GPRS
ADs ADs tr1
Req
tr2 Reply
tr3
ACK with awnd +
2
From GPRS to WLAN
Fig. 2.
Handover operations within the framework of Mobile IPv4.
a TCP proxy installed at an intermediate router in the cellular network that modifies awnd in ACKs [12]. A key limitation of this solution is its incompatibility with IPsec’s end-to-end security mechanisms [18]. With IPsec, the TCP receiver awnd is encrypted, and not readily visible to intermediate routers. IV. R ECEIVER BASED V ERTICAL H ANDOVER M ECHANISM The objectives of our mechanism are to prevent the bottleneck queue from overflowing in the GPRS network on handover from WLAN to GPRS, and to minimise the underutilisation of the WLAN capacity on handover from GPRS to WLAN. Our approach is for the MN to advertise an appropriate awnd size during vertical handover. All discussion in this paper is in the context of one TCP connection. In the case of multiple connections, the advertised window can usually be regarded as the aggregate of all the TCP flows’ advertised windows, and the allocation of the capacity of access networks has been addressed in [19]. A. WLAN to GPRS Handover In the case of WLAN-to-GPRS handover, the awnd advertised during handover can be set as: awnd = min(G_BDPmax , rwnd)
(1)
where G_BDPmax is the previously estimated maximum BDP of the GPRS network, on the assumption that the buffer allocation per mobile is configured equal in size from cell to cell (similar to the case of the allocation per-mobile of the UK Vodafone GPRS network which has been recently configured to 30KB). G_BDPmax can be accurately measured using our receiver-side BDP measurement technique: the TCP receiver counts the amount of TCP data received from the instant a timestamp is put on an acknowledgement (ACK) to the instant the TCP packet carrying the echoed timestamp has been received. The measured maximum BDP is the maximum
allowable amount of outstanding data the TCP sender should send out, which is exactly the maximum window size the TCP sender should employ. rwnd is the receiver window size, normally set according to the available buffer size of the receiver. We are interested in the maximum BDP of cellular networks only, as the actual BDP is not of that much importance: when the actual BDP is lower than the maximum, it is likely that the TCP sender will inject more packets into the cellular network than it can forward to the mobile user, but the only consequence will be excess queuing at the base station following handover, rather than buffer overflow. For this strategy to be effective, it is important to send a Mobile IP registration request at the appropriate time. Freeze-TCP faces a similar issue in considering how much in advance of the disconnection the receiver should start advertising a window size of zero, i.e. the warning period. In our algorithm, there is a similar trade-off in the selection of an appropriate time when a reduced value of awnd is advertised: if awnd is reduced too soon, the WLAN capacity will be under-utilised prior to handover; if awnd is reduced too late, buffer overflow at the SGSN could still occur if the reduced awnd has not taken effect at the TCP sender before the handover has completed at the HA. In our mechanism, when an impending handover is detected, the MN sends a copy of the last ACK with the awnd set according to (1) at an appropriate time before it has to initiate the handover, and also applies the reduced awnd to all subsequent ACKs. Following transmission of the copy of the last ACK, a Mobile IP registration request is scheduled to register the Care of Address (CoA) of the GGSN with the HA. In response to the request, the HA will set up a tunnel to the GGSN, and then respond with a registration reply sent first to the GGSN, and then forwarded to the MN. From then on, the HA redirects all TCP traffic to the GPRS network. On receipt of an ACK with a smaller awnd, the TCP sender will immediately limit the amount of outstanding data. As a result, the sender is unable to transmit sufficient packets to cause buffer overflow at the SGSN. The handover operations within the framework of Mobile IPv4 are illustrated in Fig. 2. Initially, advertisement packets (AD) arrive from both the cellular BS and the WLAN AP. When an imminent handover is detected at ta1 , instead of immediately sending out a registration request to the HA to register the CoA for GPRS, the MN postpones sending out a registration request for a period of Td seconds following the copy of the last ACK with the awnd size set to the maximum BDP for GPRS (sent out at ta1 ). It is assumed that by monitoring the WLAN signal strength, the MN will be able to predict an imminent handover to the GPRS network. This will allow the MN to start advertising the new awnd Td seconds before it has to initiate registration. In response to this ACK, which is received at ta2 , the CN will restrict the amount of outstanding data to less than the value of the new awnd. After a period Td , the MN sends the registration request at time tr1 , and this arrives at the HA at time tr2 . From time tr2 onwards, the HA redirects all subsequent packets to the GPRS network. The last TCP packet sent just before the new awnd takes effect is received at the HA at time ta3 , on its way to the WLAN AP. Therefore, if tr2 < ta3
GOU et al.: A RECEIVER-BASED VERTICAL HANDOVER MECHANISM FOR TCP CONGESTION CONTROL
and some packets are redirected to the GPRS network before the new awnd takes effect, the SGSN’s buffer queue may still be filled to overflowing. To avoid this problem, the value of Td should be chosen to ensure that tr2 ≥ ta3 . The estimation of Td must be made by the MN, and can be conveniently related to the difference between the propagation delays Tack and Treg , given by Td = max(Tack − Treg , 0)
(2)
where Tack is the one-way delay for an ACK transferred from the MN through the WLAN AP to the CN plus the propagation delay for the last packet sent just before the new awnd takes effect transferring from the CN to the HA (ta3 − ta1 in Fig. 2), and Treg is the one-way delay for a registration request transferred from the MN through the GPRS to the HA (tr2 − tr1 ). Treg is easily estimated, since it is approximately equal to half the registration round-trip-time with the cellular link involved (rttMN−BS−HA ), and this can be estimated by observing the time from the instant a registration request is sent to receipt of a corresponding registration reply. (This approximation is equivalent to the assumption that delays in the MN−BS−HA path are symmetrical.) At any time prior to the registration of the CoA for the GPRS network, rttMN−BS−HA can be measured without affecting the current binding by sending registration requests with the ‘s’ bit set, requesting that the HA retains its prior mobility bindings, and with the ‘Lifetime’ field set to zero, requesting the HA not to simulcast packets to the GPRS network as requested by the ‘s’ bit [2]. Tack can be estimated by observing the time between transmission of a registration request and reception of its corresponding registration reply via the WLAN link plus the round-trip-time between the HA and the CN, rttHA−CN . In turn, rttHA−CN is approximately equal to the difference between rttMN−AP−HA and the TCP Round-Trip-Time (RTT) rttMN−AP−CN , which can be estimated at the receiver’s end using Dynamic Right-Sizing (DRS) [20], or by using the TCP timestamp option [21]. In practice, based on these round-trip-time estimations, (2) can be substituted by: rttMN−AP−HA Td = max rttMN−AP−CN − 2 rttMN−BS−HA ,0 (3) − 2 where the three round-trip-times are computed using the firstorder low-pass filter: rtt ← η · rtt + (1 − η) · mrtt
(4)
where η is a smoothing factor with a recommended value of 7/8, the value used by TCP in its RTT estimation algorithm [22]. The resulting round-trip-time is updated every time a new round-trip time measurement (mrtt) is made.
2827
section VI) due to the absence of sufficient duplicate ACKs to trigger fast retransmit of these packets over the faster WLAN interface. In our mechanism, however, the use of a smaller awnd in the GPRS network allows the MN to increase the awnd by two segments per TCP connection on handover to WLAN, and this will permit the TCP sender to send more data, benefiting from the fact that a TCP sender can continue to increase its cwnd when the amount of outstanding data is limited by the awnd. This will result in a burst of three transmitted packets from the sender which in turn will produce three duplicate ACKs to trigger fast retransmission of those packets still queued at the SGSN. Increasing the awnd by more than two packets will lessen the under-utilisation, but will result in a burst of packets being transmitted by the CN which may overflow buffers in the intermediate routers. Following the handover, the awnd can be gradually increased up to the maximum value to make full use of the available data rates from the WLAN, based on updated estimates of the BDP of the network. The actual algorithm used to achieve this is not relevant to the handover schemes described in this paper. V. S IMULATION E NVIRONMENT We have carried out simulations using ns-2 [23] to evaluate the performance of three common variants of TCP (SACK, FACK, NewReno) on handover, with and without our mechanism. We only consider the differences in the data rate and link latency between GPRS and WLAN. A. Implementation Details The base ns distribution (ns-allinone-2.26) was patched with the ‘ns wireless extension’ module to allow basic Mobile IPv4 protocol operations [24], and amended to implement our proposed mechanism. Four modifications have been made, all based at the mobile device. The first is the BDP measurement, the algorithm of which has been detailed in section IV-A. The second modification is the addition of a second wireless interface; the cellular interface is implemented based on the preamble-based TDMA protocol [23] and the WLAN interface is implemented assuming the use of an IEEE 802.11 LAN. The third is the addition of a TCP awnd controller module, whose functions are to apply an appropriate awnd to the window size field of ACKs, and to retransmit ACKs with updated awnd values when required. The last modification is a minor change to the operation of the Mobile IP protocol at the mobile node to control the instant at which the first registration request is transmitted when an impending handover from the WLAN to the GPRS network is detected. On handover from the cellular system to the WLAN, again underlying layer information is needed to assist with prediction, but no alterations are required to the Mobile IP protocol, and the registration process is undertaken without any delay. All ACKs transmitted over the WLAN network have their awnd set to the higher value optimal for WLAN.
B. GPRS to WLAN Handover On handover from GPRS to WLAN, TCP is unable to do anything about the under-utilisation problem resulting from the slowly draining queue at the SGSN (as illustrated later in
B. Simulation Scenarios Fig. 1 depicts the scenario of interest consisting of a GPRS network overlaying a WLAN hot spot, and Fig. 3 shows
2828
IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 5, NO. 10, OCTOBER 2006
Fig. 3.
Simulation topology.
20 18
Measured BDP (packets)
16 14 12 10 8 6 4 2 0 10
Fig. 4.
20
30
40
50 60 Time (s)
70
80
90
100
BDP measurement in GPRS.
our simulation topology. An FTP session is examined, with the CN designated as the sender and the MN designated as the receiver. Following [16] and [22], we set the Maximum Transmission Unit (MTU) to 1500 bytes for both the WLAN and GPRS networks. To account for the 20-byte IP header and 20-byte TCP header, the total size of the TCP Maximum Segment Size (MSS) and potential TCP options is set to 1460 bytes. IETF RFC 3481 [25] specifies that implementations of TCP over 2.5G or 3G networks should support the selective acknowledgment option (SACK) [6], or in the absence of the SACK feature, TCP should use NewReno [7]. Linux TCP uses a Forward Acknowledgment (FACK) algorithm by default, which represents a modification of TCP SACK and is described in [5]. We have evaluated the performance of our mechanism with all three TCP variants but focus on TCP SACK and NewReno due to space constraints and their greater applicability to the scenario of interest. It is worth noting
that whilst our implementation is for Mobile IPv4, the same issues apply to Mobile IPv6 and the proposed mechanism and modifications can also be easily implemented for Mobile IPv6. For example, in Hierarchical Mobile IPv6 [26], the Mobility Anchor Point (MAP) performs the function of a “local” HA. When the MN moves within the same MAP domain, it only registers its new CoA with its MAP. Otherwise, the operation of Hierarchical Mobile IPv6 with our awnd based vertical handover mechanism is virtually the same as the operation in the context of Mobile IPv4. The GPRS interface is implemented based on ns-2’s preamble-based TDMA MAC protocol [23]. A drop-tail policy is often applied to radio network queues [17]. In our simulation, we use a priority-based drop-tail queue, which gives a higher priority to Mobile IP protocol messages than TCP packets by inserting Mobile IP protocol messages at the head of the queue and serving them first. This enables the Mobile IP protocol to operate independently of the TCP traffic. We set the SGSN buffer allocation to 30KB to be compatible with the current UK Vodafone allocation, which is equivalent to twenty 1500-byte packets [12]. The data rate of the TDMA model is set to around 50 Kbps, which represents a typical figure that can be achieved over a GPRS network, given that data rates up to 43 Kbps have been observed [11] despite a theoretical limit of 171 Kbps. The raw data rate of the WLAN link is set to 5.5 Mbps, one of the available bit rates of the IEEE 802.11b standard [27]. We assume that the queue at the AP is large enough to accommodate a maximum sized window of TCP packets (up to 64 KB payload) at all times. In our simulation, the buffer allocation per mobile at the SGSN is twenty packets. To take into account other non-TCP traffic, such as Mobile IP messages, we use eighteen segments during handover as the awnd in GPRS, two packets smaller than the measured maximum BDP supported by the GPRS network in our simulation, as shown in Fig. 4. We use fortyfive segments as the awnd for WLAN, which is the maximum number of segments permissible within the constraints on awnd (64 KB) without using the window scale option [22]. Other parameters in the scenario are given in Fig. 3. During the simulation of a WLAN-to-GPRS handover, the MN moves linearly at the speed of 1m/s (typical walking speed), from the WLAN hotspot to an area where the only coverage is via the GPRS network. For a GPRS-to-WLAN handover, the MN moves in the reverse direction. The relevant simulation parameters are summarised in Table I. VI. R ESULTS In this section we show the benefits of using our mechanism compared to the default behaviour of Mobile IPv4 with the TCP variants considered for this work. We consider both cases of vertical handover separately, starting with the case of vertical handover from the high-BDP WLAN to the lowBDP cellular network. A. WLAN to GPRS Handover To examine the impact of handover from WLAN to GPRS, an FTP session was started ten seconds into the simulation,
GOU et al.: A RECEIVER-BASED VERTICAL HANDOVER MECHANISM FOR TCP CONGESTION CONTROL
2829
TABLE I S IMULATION PARAMETERS Parameter
Advertised Window Size
Internet One-Way Link HA-BS One-Way Link HA-AP One-Way Link Cellular Link
WLAN Link
TCP IP Mobile IP Data Traffic
WLAN-to-GPRS handover GPRS-to-WLAN handover
WLAN GPRS GPRS WLAN
Data Rate Delay Data Rate Delay Data Rate Delay Data Rate Queue Management Queue Size Data Rate Queue Management Queue Size MSS + TCP Options SACK-enabled Variants MTU
Value 45 segments 45 (normal) 18 (two less than the maximum measured BDP, our mechanism) 12/18 segments 12/18 (normal) 12/18 increased by 2 (our mechanism) 1 Gbps 50 ms 10 Mbps 10 ms 100 Mbps 10 ms 50 kbps Priority-based drop-tail policy 20 packets 5.5 Mbps Priority-based drop-tail policy 50 packets 1460 bytes On SACK, FACK, NewReno 1500 bytes Mobile IPv4 An FTP session
with the MN starting to move linearly through the WLAN coverage region at the same time. The problem examined in this instance is buffer overflow in the GPRS network during the handover process. The MN detects deterioration in the WLAN signal 15.8 seconds into the simulation, which indicates an impending handover. The resulting flow of packets obtained with TCP SACK is shown in Fig. VI-A. Initially, the MN uses an awnd set for the WLAN of 45 segments. Following the handover, a burst of packets is sent to the GPRS network, and the SGSN buffer overflows, as it is only dimensioned to hold twenty packets. The CN, however, continues to send packets before receiving three duplicate ACKs after 24.1 seconds; these packets are subsequently received out of order at the mobile node. Fast retransmit and fast recovery are then initiated, and the oldest outstanding segment (the first segment dropped) is retransmitted. This retransmitted packet does not reach the receiver until all preceding out-of-order packets leave the path. This delay could be even longer in practice if the SGSN buffer size were larger. During fast recovery, SACK only sends new or retransmitted data when the estimated number of packets in the path is less than cwnd. If the number of lost packets is too large, SACK cannot recover without resorting to a timeout, which in this case occurs after 27.5 seconds. After 40 seconds have elapsed, the ACK that acknowledges all segments the receiver has received so far causes another burst of packets to be lost at the SGSN, which in turn causes another fast recovery. For SACK TCP, the sender knows from the SACK options which packets the receiver has received, however, the use of timeouts as a fall-back mechanism for detecting dropped packets is unchanged by the SACK option. The receiver is allowed to discard previously selectively acknowledged data,
so that when a retransmit timeout occurs, the data sender must ignore prior SACK information in determining what data to retransmit [6]. Therefore, the timeout generates a significant number of unnecessary retransmissions. Fig. VI-A shows the case when a packet gets dropped prior to handover, which may occur when handing over from a WLAN to a GPRS network and the wireless channel between the mobile node and the access point degrades rapidly. It shows that if, prior to handover, the TCP window size in the WLAN is larger than the buffer allocation per mobile in the GPRS network, buffer overflow will take place independent of whether there is packet loss or not. Fig. 6 shows the corresponding performance of TCP NewReno, which suffers in nearly the same way as TCP SACK. It is clear that the TCP flow is severely interrupted by the handover for both TCP variants, and there is likely to be a significant degradation in the perceived quality to the user. If the link is being used for delay sensitive applications such as streaming audio or video, this level of interruption is unacceptable. The corresponding behaviour when our handover mechanism is incorporated is shown in Fig. 7. This plot shows that our proposed vertical handover mechanism is extremely effective, eliminating the buffer overflow problem at the SGSN during handover. The whole handover is completed with a smooth transition between the two disparate rates of data reception at the MN. There are no retransmissions on handover, and more importantly, there is no interruption to the flow of insequence packets delivered to the MN. In this case, the actual BDP of the GPRS network is lower than its maximum, and the only consequence is that the excess queue in the GPRS network stays at a higher level following the handover.
IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 5, NO. 10, OCTOBER 2006
1140
1140
1120
1120 Fast Retransmit
Fast Retransmit
1080
40 Receiver Data Sender Data Sender ACK BS Overflow BS Queue Length
1060 TCP Timeout 1040
20 10
1020 1000 15
30
20
25
30
35 Time(s)
40
45
50
Fast Retransmit
1100 Fast Retransmit
1080 1060
TCP Timeout
0 55
20
1020
10
1000 15
20
25
1140
1120
1120
1100 1080
40 30
1060 TCP Timeout
1040
20
1020
10
30
35 Time(s)
40
45
50
0 55
Segment Number
1140
BS Queue Length (Packet)
Segment Number
1160
25
30
35 40 Time(s)
45
50
0 55
(a) TCP NewReno
1160
20
30
1040
(a) TCP SACK
1000 15
40 Receiver Data Sender Data Sender ACK BS Overflow BS Queue Length
1100
30
1060 TCP Timeout 1040
20
1020
10
1000 15
(b) Pkt 1000 dropped prior to handover Fig. 5. TCP SACK during handover from WLAN to GPRS. The receiver trace is offset by 55 segments and starts from 16.5 seconds into the simulation to prevent overlap with the sender trace.
40
1080
20
25
30
35 40 Time(s)
45
50
BS Queue Length (Packet)
1100
BS Queue Length (Packet)
1160
Segment Number
1160
BS Queue Length (Packet)
Segment Number
2830
0 55
(b) Pkt 1000 dropped prior to handover Fig. 6.
TCP NewReno during handover from WLAN to GPRS.
B. GPRS to WLAN Handover
We have also evaluated the performance of TCP FACK on handover. Since TCP FACK recovers more aggressively during fast recovery, lost packets are quickly retransmitted. However, under most circumstances some of the retransmitted packets will be lost due to SGSN buffer overflow, and under these conditions a timeout is deliberately forced to prevent FACK from being too aggressive [5]. Since our mechanism avoids retransmitted packets during handover, TCP FACK with our mechanism performs exactly as shown in Fig. 7. In summary, TCP Reno and NewReno with the TCP timestamp option enabled, independent of SACK or FACK options, all benefit from our scheme, and have exactly the performance shown in Fig. 7.
To examine the impact of handover from the GPRS network to the WLAN, an FTP session was started ten seconds into the simulation, with the MN starting to move linearly towards the WLAN coverage region after 30 seconds have elapsed. The relevant problem in this case is the under-utilisation of WLAN capacity during and immediately after handover. The resulting flow of packets obtained with TCP SACK and TCP NewReno is illustrated in Fig. 8. Even though the registration of the new CoA of the AP has been accomplished, there are still a large number of packets queued at the SGSN and the first packet sent to the WLAN arrives at the MN out of order. However, this out-of-order packet only generates one duplicate ACK, which is insufficient to trigger TCP’s fast retransmit process. Additional packets are sent over the WLAN link at the same rate as ACKs are received, so packets arrive at the MN alternately from the
GOU et al.: A RECEIVER-BASED VERTICAL HANDOVER MECHANISM FOR TCP CONGESTION CONTROL
2831
200
1160 1140
Receiver Data Sender Data Sender ACK BS Queue Length
180
1120
Receiver Data Sender Data Sender ACK BS Overflow BS Queue Length
1060
30
1040
20
1020
10
1000
15
20
25
30
35 40 Time(s)
45
50
0 55
140
40
120
30
100
20
80
10
60
(a) TCP NewReno improved by our scheme
35
36
37
38 39 Time(s)
40
41
42
BS Queue Length (Packet)
40
1080
Segment Number
1100
BS Queue Length (Packet)
Segment Number
160
0
(a) awnd in GPRS prior to handover: 12 segments
1160
200
1140
180
40
1060
30
1040
20
1020
10
1000
15
20
25
30
35 40 Time(s)
45
50
0 55
(b)Pkt 1000 dropped when improved by our scheme Fig. 7. TCP NewReno integrated with our scheme during handover from WLAN to GPRS.
GPRS and WLAN interfaces. The results presented in Fig. VI-A have been obtained with an awnd of 16KB, which represents the default value used by many operating systems [25]. The larger the awnd, the more time it takes for the SGSN queue to drain, which intensifies the under-utilisation of WLAN capacity during handover, as shown in Fig. VI-A. On the other hand, with a smaller value of awnd, the WLAN capacity after handover is under-utilised because the value of awnd is significantly less than the BDP of the WLAN. This contradiction between the requirements for the awnd size in heterogeneous mobile wireless networks, especially during vertical handover, is a fundamental problem. The behaviour on handover from the GPRS network to WLAN when our mechanism is incorporated into TCP NewReno is shown in Fig. 9. Compared with the performance obtained with standard TCP NewReno and SACK (shown in Fig. 8), it can be seen that our proposed mechanism signifi-
140
40
120
30
100
20
80
10
60
35
36
37
38 39 Time(s)
40
41
42
BS Queue Length (Packet)
1080
Segment Number
160 1100
BS Queue Length (Packet)
Segment Number
1120
0
(b) awnd in GPRS prior to handover: 18 segments Fig. 8. Under-utilisation during handover from the GPRS network to the WLAN for TCP SACK and NewReno. (The vertical line indicates the registration accomplishment, corresponding to tr3 in Fig. 2. The receiver trace is offset by 25 segments to prevent overlap with the sender trace.)
cantly reduces the under-utilisation of WLAN capacity during handover. With our mechanism, once the registration reply message is received (indicated by the vertical line at around 35.8 seconds), the MN increases its awnd by two segments, and applies it to subsequent ACKs. On receipt of an ACK with a larger awnd at second 36, the CN sends two more packets out because the permitted amount of outstanding data has been raised. These packet transmissions generate three duplicate ACKs, which in turn allows TCP’s fast retransmit/fast recovery process to start 36.1 seconds into the simulation, much faster than previously. During fast recovery, TCP NewReno retransmits one lost packet per RTT until fast recovery ends after around 37.4 seconds. During fast recovery, partial ACKs that acknowledge some but not all of the packets that were outstanding at the be-
2832
IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 5, NO. 10, OCTOBER 2006
200 Receiver Data Sender Data Sender ACK BS Queue Length
180
(*) Two more packets triggered by awnd being increased by two
140
40
30
120
20
100 (*) Fast recovery ends
80
10
BS Queue Length (Packet)
Segment Number
160
Fast Recovery starts 60
35
36
37
38 39 Time(s)
40
41
42
0
(a) Fig. 8(a) improved by our scheme 200
VII. C ONCLUSIONS AND F UTURE W ORK
180
(*) Two more packets triggered byawnd being increased by two
140
40
120
30
100
20 (*)
80
Fast recovery ends
10
Fast Recovery starts 35
36
37
38 39 Time(s)
40
41
42
BS Queue Length (Packet)
Segment Number
160
60
a variable called pipe to represent the estimated number of outstanding packets in the path. A duplicate ACK with a SACK option reporting new data received at the receiver decreases the estimated number of outstanding packets by one and a partial ACK decreases the estimated number of packets in the path by two packets. Whenever pipe is less than cwnd, a number of packets equal to the difference will be retransmitted. Hence, the TCP sender is able to rapidly retransmit packets left queuing at the SGSN over the much faster WLAN interface. This mechanism for fast recovery explains why TCP SACK takes less time to complete the retransmission than TCP NewReno. TCP FACK has also been evaluated under the same conditions. Unlike SACK and NewReno, FACK can initiate fast recovery, with cwnd set to one, by a single duplicate ACK that indicates that the difference between the sequence numbers in the newly arrived packet and the last arrived packet is greater than three segments. As a result, FACK is able to quickly start to make full use of the WLAN in the same way without requiring an increased awnd.
0
(b) Fig. 8(b) improved by our scheme Fig. 9. TCP NewReno integrated with our scheme during handover from GPRS to WLAN.
ginning of the fast recovery period effectively indicate the loss of the packet immediately following the last acknowledged packet in the sequence space, which is then retransmitted [28]. Our mechanism has mitigated the problem of under-utilisation of the WLAN capacity during handover. The packets transmitted by the BS that have already been retransmitted and received via the WLAN interface consume valuable radio spectrum. Many cellular networks include a mechanism for reducing this waste: for example in the case of GPRS, the MN can signal the HA, which in turn signals the SGSN of the GPRS BS using the Base Station Subsystem GPRS Protocol (BSSGP), requesting a release of all resource reservations for the MN and a discard of all buffered data [11]. When our mechanism is applied to TCP SACK, similar results are obtained, and it also shows than TCP SACK performs even a little better than TCP NewReno. SACK maintains
In this paper we have proposed a receiver-based handover mechanism for TCP to deal with two key problems associated with vertical handover between networks with significantly different link capacities and latencies. Our focus has been on make-before-break vertical handover in a scenario consisting of a WLAN hot spot overlaid with a cellular network. These networks are characterised by very different link capacities, which has a severe impact on the performance of standard TCP variants during handover. When handing over from a high-BDP WLAN to a low-BDP GPRS network, the buffer in the GPRS network can experience overflow with significant packet loss, causing TCP to take a long time to recover, and in turn causing unacceptable degradation of the perceived quality to the user, especially for delay sensitive applications such as streaming audio or video. When handing over from a lowBDP GPRS network to a high-BDP WLAN, TCP is unable to adapt to effectively utilise the WLAN, which results in underutilisation of the WLAN capacity. We propose an algorithm for accurately measuring the maximum BDP supported by the networks, which can also be used to measure the buffer allocation per mobile in GPRS cellular networks. Our proposed vertical handover mechanism uses receiver-based congestion control at the mobile node to ensure smooth handover from one network to another by adapting the advertised window to suit the access network characteristics. All modifications are restricted to the mobile node, which entirely meets the recommendation on deployment specified in [15], and are compatible with existing versions of IPsec, Mobile IP and TCP, and can be used with unmodified access points, base stations, home agents, correspondent nodes and intermediate routers. Our results show that the problems of packet dropping, service interruption and under-utilisation are inevitable for the considered TCP variants during vertical handover, resulting in unacceptable performance on handover for delay-sensitive applications. Standard TCP variants are unaware of underlying
GOU et al.: A RECEIVER-BASED VERTICAL HANDOVER MECHANISM FOR TCP CONGESTION CONTROL
changes in advance of a handover and only react passively. Integrated with our proposed receiver-based vertical handover mechanism on the basis of available information at the mobile node, these problems can be effectively solved. Techniques for optimising the receiver’s advertised window size, based on measurement of the sender’s congestion window at the receiver [20], [21], [29], the current channel rate available from the physical layer [30], and information on neighbouring access routers and their capabilities [31], are one subject of future work, as are the new features required to take advantage of the multi-homing capabilities of Mobile IPv6. ACKNOWLEDGMENT The authors would like to thank Ji Zhang for his helpful suggestions about the timing issue on handover, and Ben Weaver for his assistance in preparing this paper. R EFERENCES [1] D. Johnson, C. Perkins, and J. Arkko, “Mobility support in IPv6,” RFC 3775, June 2004. [2] C. Perkins, “IP mobility support for IPv4,” RFC 3344, Aug. 2002. [3] K. E. Malki and H. Soliman, “Simultaneous bindings for Mobile IPv6 fast handovers,” Internet Draft, Oct. 2003. [4] M. Allman, V. Paxson, and W. Stevens, “TCP congestion control,” RFC 2581, Apr. 1999. [5] M. Mathis and J. Mahdavi, “Forward acknowledgment: Refining TCP congestion control,” in Proc. ACM SIGCOMM, Stanford, CA, Aug. 26– 30, 1996, pp. 281–191. [6] M. Mathis et al., “TCP selective acknowledgment options,” RFC 2018, Oct. 1996. [7] S. Floyd, T. Henderson, and A. Gurtov, “The NewReno modification to TCP’s fast recovery algorithm,” RFC 3782, Apr. 2004. [8] A. K. Salkintzis, C. Fors, and R. Pazhyannur, “WLAN-GPRS integration for next-generation mobile data networks,” IEEE Wireless Commun., vol. 9, no. 5, pp. 112–124, Oct. 2002. [9] J. Manner and M. Kojo, “Mobility related terminology,” RFC 3753, June 2004. [10] R. Chakravorty, J. Cartwright, and I. Pratt, “Practical experience with TCP over GPRS,” in Proc. IEEE GLOBECOM, Taipei, Taiwan, Nov. 2002, pp. 1678–1682. [11] A. Gurtov et al., “Multi-layer protocol tracing in a GPRS network,” in Proc. IEEE 56th Vehicular Technology Conference, Sept. 24–28, 2002, pp. 1612–1616. [12] R. Chakravorty et al., “On inter-network handover performance using Mobile IPv6,” University of Cambridge Technical Report, Tech. Rep., June 2003. [13] T. Goff et al., “Freeze-TCP: A true end-to-end TCP enhancement mechanism for mobile environments,” in Proc. IEEE INFOCOM, Mar. 26–30, 2000, pp. 1537–1545. [14] S.-E. Kim and J. A. Copeland, “TCP for seamless vertical handoff in hybrid mobile data networks,” in Proc. IEEE GLOBECOM, San Francisco, CA, Dec. 1–5, 2003, pp. 661–665. [15] G. Montenegro and S. Dawkins, “Wireless networking for the MNCRS,” Internet Draft, Aug. 1998. [16] A. Gurtov and J. Korhonen, “Effect of vertical handovers on performance of TCP-friendly rate control,” ACM SIGMOBILE Mobile Computing and Communication Review, vol. 8, no. 3, pp. 73–87, July 2004. [17] R. Ludwig et al., “Multi-layer tracing of TCP over a reliable wireless link,” in Proc. ACM SIGMETRICS, Atlanta, GA, May 1999, pp. 144–154. [18] S. Kent and R. Atkinson, “Security architecture for the Internet Protocol,” RFC 2401, Nov. 1998. [19] L. Andrew, S. Hanly, and R. Mukhtar, “CLAMP: Differentiated capacity allocation in access networks,” in Proc. IEEE International Performance Computing and Communications Conference, Phoenix, AZ, Apr. 9–11, 2003, pp. 451–458.
2833
[20] M. Fisk and W. Feng, “Dynamic right-sizing in TCP,” in Proc. IEEE International Conference on Computer Communications and Networks, Oct. 2001. [21] J. W. Heffner, “High bandwidth TCP queuing,” Senior Thesis, Pittsburgh Supercomputing Center, Carnegie Mellon University, Pittsburgh, PA, July 2002. [22] W. R. Stevens, TCP/IP illustrated: The protocols. Addison-Wesley, 1994, vol. 1. [23] K. Fall and K. Varadhan, “The ns manual,” Dec. 2003. [Online]. Available: http://www.isi.edu/nsnam/ns/ns-documentation. html [24] J. Widmer, “Extensions to the ns network simulator,” 2003. [Online]. Available: http://www.informatik.uni-mannheim.de/ informatik/pi4/projects/MobileIP/ns-extension [25] H. Inamura et al., “TCP over second (2.5G) and third (3G) generation wireless networks,” RFC 3481, Feb. 2003. [26] H. Soliman et al., “Hierarchical Mobile IPv6 mobility management,” Internet Draft, June 2004. [27] IEEE, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications,” IEEE Std 802.11b-1999, 1999. [28] K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno, and SACK TCP,” ACM SIGCOMM Computer Communication Review, vol. 26, no. 3, pp. 5–21, July 1996. [29] D. S. Miller, “Linux v2.6.7,” June 2004. [Online]. Available: http: //www.kernel.org [30] D. S. Lee and C. C. Lin, “Window adaptive TCP for EGPRS networks,” Journal of Information Science and Engineering, vol. 20, no. 5, pp. 805– 820, Sept. 2004. [31] M. Liebsch, “Candidate access router discovery,” Internet Draft, Sept. 2004. Yuci Gou received a BEng from Beihang University in 1999, and an MSc from the University of York in 2005. As a Senior Software Engineer, he has two years of expertise in designing and developing IP-based networks at Harbour Networks Limited in Beijing. His research interests are in network protocols, network performance evaluation, mobile networking and emergency communications systems.
David Pearce received a BA from the University of Cambridge in 1985, and a DPhil from the University of York in 2001. He is now a lecturer in communications at the University of York, where his research interests are in spectrum management, radio resource allocation and access and network layer protocols for the wireless Internet.
Paul Mitchell is a lecturer in the Communications Research Group at the University of York. He received his MEng and PhD degrees from York in 1999 and 2003 respectively. He has worked extensively on resource allocation for satellite systems at York, in collaboration with BT. Primary areas of expertise include medium access control, traffic modelling, queuing theory, and system level simulation. He has industrial experience in wireless communications from BT and QinetiQ. Current research activity is focussed on medium access control for wireless sensor networks, with other interests in satellite systems, high altitude platforms, and higher layer protocols. He is an author and reviewer of refereed journal and conference papers on wireless communications, and has been an invited speaker at the Universities of Bradford and York to give lectures on resource allocation techniques. He is a member of the IEE professional network on Satellite Systems and Applications.
