Skip to content

Advertisement

  • Research
  • Open Access

TCP-based window-size delegation method for TXOP Exchange in wireless local area networks

  • 1Email author,
  • 1,
  • 1 and
  • 2
EURASIP Journal on Wireless Communications and Networking20112011:58

https://doi.org/10.1186/1687-1499-2011-58

  • Received: 2 February 2011
  • Accepted: 11 August 2011
  • Published:

Abstract

We propose a TCP window-size delegation method for downlink TXOP (transmission opportunity) Exchange in wireless local area networks (WLANs). In our method, the 'compliant' stations (STAs) cooperatively use their available bandwidth in accordance with their throughput demand. We realize our method only with minimal modifications of the TCP functions of a proxy server, which lets one station (the TXOP provider) delegate TCP window size to another station (the TXOP client) so that the provider delegates its TXOPs in WLANs to the client. Our method enables an STA to flexibly delegate TXOPs to another STA without adversely affecting the legacy STAs, which is confirmed by computer simulations. We also confirmed that our method requires no modification to legacy access points and STAs.

Keywords

  • Bandwidth delegation
  • TCP window size
  • TXOP Exchange
  • Wireless local area networks

1 Introduction

In offices, homes, and public spaces, IEEE 802.11 wireless local area networks (WLANs) has been extensively used to provide wireless Internet connection services. In WLANs, stations (STAs) connected to an access point (AP) compete for transmission opportunities (TXOPs) using the carrier sense multiple access with collision avoidance (CSMA/CA). TXOPs are almost equally assigned to the STAs and the AP without considering each STA's throughput demand, especially when the traffic load is heavy. Although many quality of service (QoS) control mechanisms applicable for WLANs have been proposed including IEEE 802.11e, IntServ and DiffServ [13], they are not widely used basically because they require 'physical replacement' of existing APs or edge routers.

To solve this problem, we proposed TXOP Exchange [46]. In WLANs, the number of TXOPs obtained by each STA determines the throughput of the STA. Therefore, for the uplink, we modified only the STA-side media access control (MAC) protocol so that the STAs participating in TXOP Exchange (compliant STAs) can directly delegate TXOPs without affecting the performances of the other STAs. In TXOP Exchange, compliant STAs cooperatively use their available bandwidth in accordance with their required throughputs. Consider an example of a wireless access network with one AP, two STAs compliant with our architecture, and other STAs. Each of the STAs is downloading a large file, like a video file or a zipped file of photos, to a storage server. The throughput of the STAs is saturated at 800 Kbps. Suppose that one of the compliant STAs, STA 1, wants to increase its throughput to 1 Mbps to download its file faster. If the other compliant STA, STA 2, is not interested in downloading its file faster, then, as shown in Figure 1, it can delegate some of its TXOPs to STA 1 so that the throughput of STA 1 increases up to 1 Mbps. Throughput increase is always beneficial for STAs regardless of how much it is particularly when they download files or receive audio/video streams with progressive download. In this example, STAs 1 and 2 are a TXOP client and a TXOP provider, respectively. Each compliant STA can become a provider or a client as necessary. Thus, cooperative exchange of TXOPs enables STAs to satisfy the throughput requirements each other. TXOP Exchange enables compliant STAs to flexibly exchange bandwidth without modifications on the legacy APs and without affecting the performances of the other "non-compliant" STAs, as illustrated in Figure 2.
Figure 1
Figure 1

TXOP delegation in CSMA/CA.

Figure 2
Figure 2

STA B delegates some of its bandwidth to STA A. Bandwidth of STA A increases without decreasing bandwidth of STA C.

We previously focused on the use of TXOP Exchange for the uplink [4, 5]. In this paper, we focus on extending TXOP Exchange so that it can be used for the downlink as well. Unlike the uplink, we cannot realize TXOP Exchange for downlink only by MAC-layer modification at STAs since the packets are sent to the STAs from the connecting AP by using the AP's TXOP; in other words, the STAs share TXOPs of the AP for their downlink communications. On the other hand, AP sends a packet in the top of sending queue of the AP. Therefore, to enable an STA to delegate its TXOPs to another STA, we need to control the number of packets in the AP sending queue. Considering the implementation constraint and cost, we propose a transport-level control method that uses proxy servers to control the number of packets arriving at the AP. A proxy server plays roles of a coordinator between STAs and a manager for TCP connections of compliant STAs. In this method, a TXOP provider delegates a chance to increase its TCP window size to the TXOP client, which is controlled by the proxy server. The proxy server also decreases the window size for the TXOP provider where as that for the TXOP client would be decreased with the legacy TCP. This method does not require any modifications of the APs or the legacy STAs and is applicable to access networks other than WLANs since it is based on end-to-end TCP-level controls.

The rest of this paper is organized as follows. Section 2 briefly introduces our TXOP delegation method for the uplink and show how it works. In Section 3, we describe out TXOP delegation method for the downlink in detail. In Section 4, we observe how our method works through computer simulations and verify that it enables an STA to delegate throughput to another STA, while the other STAs see the same throughput as before. We also discuss the performance with varying the number of other STAs and round trip time (RTT). Finally, we mention the related work and conclude our paper in Sections 5 and 6.

2 Previous work: TXOP Exchange for uplink

3 TXOP Exchange for downlink

4 Simulation evaluation

4.1 Simulation setup

We evaluate our delegation method using QualNet simulator [7]. We assume a network in which a provider and a client download data using TCP from a corresponding server, while the other STA download data directly from another corresponding server. Each of the STAs used only one flow. We assume that a bandwidth between the proxy server and the corresponding server for the provider and the client is large enough not to limit throughputs for them. We also idealize wireless channels to make our discussion simple. For instance, when an STA with lower channel quality delegates its TXOPs to another STA with higher channel quality, the overall transmission efficiency might improve. This issue should be included in future work.

In Section 4.2, we will first observe the dependence of throughputs on α and β of our method introduced in Section 3.2. To observe the basic characteristics of the proposed method, we used the network model illustrated in Figure 9, where the wireless link is modeled as simply a wired 10 Mbps bottlenecklink; since every packet in a WLAN downlink is always sent from the AP, results from this model would not be far from the ones from a model with CSMA/CA. Therefore, here, the maximum total amount of throughputs of STAs is limited to 10 Mbps by this bottlenecklink.
Figure 9
Figure 9

Simulation model. We used QualNet 4.5.1; TCP SACK with delay-ACKs, Nagale algorithm, RFC1323, and Keepalive probes; maximum segment size was 1,500 bytes; send buffer size was 65,000 bytes; receive buffer size was 65,000 bytes; wired bottlenecklink bandwidth was 10 Mbps, while other links bandwidth were 100 Mbps.

However, in Section 4.3, we will evaluate the effectiveness and the scalability of our method with a wireless network in a WLAN access link is the bottleneck as illustrated in Figure 10. The parameters regarding the wireless link completely follow the standard of IEEE 802.11a, though we fixed the transmission rates to 24 Mbps with no channel errors. In this model, because of the MAC overhead, the total amount of throughputs of STAs is limited to approximately 13.5 Mbps when there are three STAs.
Figure 10
Figure 10

Simulation model of WLAN. We used QualNet 4.5.1; TCP SACK with delay-ACKs, Nagale algorithm, RFC1323, and Keepalive probes; maximum segment size was 1,500, bytes; send buffer size was 65,000 bytes; receive buffer size was 65,000, bytes; Access network is IEEE 802.11a WLAN with physical transmission rate of 24 Mbps; other links' bandwidth were 100 Mbps; RTT P was 10 ms while RTT o varied from 10 to 500 ms.

4.2 Dependence of throughputs on α and β

We first demonstrate how a conventional method works. As mentioned in Section 3, a simple way to increase throughput of an STA is to assign multiple flows for the STA. Figure 4 shows the throughputs of each STA as a function of the number of flows assigned to STA A. With increase the number of flows for STA A, the throughput for STA A increases, while throughputs for STAs B and C decrease. As shown in this example, the conventional method may differentiate throughputs but it affects the non-compliant STAs significantly.

We next observe how our window-size delegation work with varying given α and β, which means, here, we did not use our criteria for determining α and β described in Sections 3.3. Figures 11a, b plots the throughput of each STA as a function of β for α = 0.3 and 1.0, respectively. 'w/o delegation' means the average throughputs for STAs when our method is not used. As you first see in these figures, we successfully increased the throughput for the client compared with 'w/o delegation' by the delegation from the provider. We also observe the increased and decreased throughputs for the client and the provider increase, as given β increases. However, the throughput for the other STA is not kept equal to the one in 'w/o delegation' and depends on α and β. We see the intersection of the throughput for the other between with and without delegation at a combination of α and β, which suggests we have to choose α and β appropriately.
Figure 11
Figure 11

Throughputs for the client and the provider versus β when a α = 0.3, b α = 1.0 with one additional TCP flow other than client and provider (other). We used the model in Figure 9.

Figures 12a, b, c show the throughput of each STA as a function of α for β = 0.3, 0.5, and 1.0, respectively. We can observe from these figure that the throughput of the client remains almost unchanged and independent of α. However, the throughput for the other STA increased when α exceeded a certain point. Unless β is 0.7, when α was appropriately set, the throughput for the other STA was the same as w/o delegation.
Figure 12
Figure 12

Throughput for each STA versus α when a β = 0.3, b β = 0.5, c β = 1.0 with one additional TCP flow other than client and provider (other). The model in Figure 9 was used.

The above results suggest we have to introduce an adaptive algorithm for determining α and β appropriately. Now, we start to use our designed algorithm described in Section 3.3. Figure 13 plots the result as a function of Δ r , which is the required additional throughput from the client: how much the client wants to increase its throughput than before starting TXOP Exchange. We see in the figure that the throughput of the client is successfully controlled almost equally to Δ r without affecting that of the other STA.
Figure 13
Figure 13

Throughput for each STA versus Δ r with one additional TCP flow other than client and provider (other). Δ r indicates the required additional throughput from the client. The model in Figure 9 was used.

4.3 Performance of window-size delegation method in WLANs

We here evaluate the performance of our method with using a wireless network in Figure 10. Figure 14 shows the average throughput of each STA as a function of Δ r . In this figure, we confirm the throughput for the client is increased almost equally to Δ r compared with 'w/o delegation' without affecting the throughput for the other STA.
Figure 14
Figure 14

Average throughput of each STA versus Δ r in single-AP network with provider, client, other STA. Bottlenecklink is IEEE 802.11a WLANs with physical transmission rate of 24 Mbps.

Next, we evaluate the scalability of our method through the following two scenarios, in which the same simulation parameters are used as in Figure 11 except the number of STAs and RTTs between corresponding servers and the AP.

First, we investigate a case where the number of other STAs varies. We assume a network with a provider, a client, and N o other STAs. RTTs here were identically set to 10 ms. Figure 15 plots the average throughput of each STA as a function of N o , in which 'w/o delegation (compliant)' indicates the throughput of compliant STAs which download data from the proxy server without the window-size delegation, while 'w/o delegation (other)' indicates the throughput of other STAs which download data from their corresponding server without the window-size delegation. We fixed the required throughput Δ r to 300 Kbps. As seen in the figure, regardless of N o , the client keeps its increased throughput approximately 300 Kbps larger than that in 'w/o delegation (compliant)'. We also see the throughputs of the other STAs did not change from 'w/o delegation (others)'.
Figure 15
Figure 15

Average throughput of each STA versus N o in network with provider, client, and other N o STAs. Bottlenecklink was IEEE 802.11a WLAN with physical transmission rate of 24 Mbps. RTTs between AP and corresponding servers were identically 10 ms.

Second, we investigate a case where RTT between the corresponding server for other STAs and the AP RTT o is different from RTT between the proxy server and the AP RTT P . Since the proxy server is located in the same as the AP and the others' corresponding server is located in somewhere in the Internet, RTT o can be a little or much larger than RTT P . We assume that RTT P was 10 ms while RTT o varied from 100 to 500 ms. We fixed the total number of STAs to 10, which consists of a provider, a client and eight other STAs. Figure 16 shows average throughputs of each STAs versus RTT of flows for others. We set the required throughput Δ r to 600 Kbps. This figure also shows that the client maintains its increased throughput approximately 600 Kbps larger than compared with 'w/o delegation (compliant)' while others' throughputs are not changed regardless of RTT. As in the above observations, our method enables the client to increase its throughput, which is always beneficial regardless of how much the increase is particularly when they download files or receive audio/video streams with progressive download as described in Section 1.
Figure 16
Figure 16

Average throughput of each STA versus RTT of flows for others. There are provider, client, and eight other STAs. RTTs between AP and corresponding server for provider and client were 10 ms, while RTT for the other varied as x axis. Bottlenecklink was IEEE 802.11a WLAN with physical transmission rate of 24 Mbps.

5 Related work

Our window-size delegation method in Section 3 enables an STA to delegate its throughputs to another STA in accordance with the required throughput without any effect on other STAs. Our method requires only a proxy server which is compliant with our method. To the best of our knowledge, any conventional methods cannot do this. In this section, we introduce several conventional methods as below.

Many flow level QoS control methods have been proposed including IntServ and DiffServ architectures [2, 3, 9, 10]. In [2, 3, 9], their approaches are basically to control bandwidths and/or delays of flows between edge routers. They can differentiate throughput and/or delays among flows, while they require replacements or modifications on edge routers, which are limited to their application range. On the other hand, it has been discussed how to prioritize throughputs for specific STAs with only modifications on a server [10]. In [10], when a server receives duplicate ACKs from prioritized STAs, the server decreases congestion window size of flows for other altruistic STAs instead of the prioritized STA's congestion window size. However, this method cannot ensure to increase a throughput of prioritized STA when the number of altruistic STAs is not satisfactorily large.

On the other hand, in WLANs, MAC level QoS control methods also have been proposed including a QoS standard of WLANs called IEEE 802.11e [1]. The AP equipped with IEEE 802.11e can prioritize packets classified as specific traffic like video and voice and differentiate throughputs for them from the other traffic. However, it does make it without giving some effect on other STAs in the network especially when the network includes non-compliant STAs. Cooperation methods have been also discussed [11, 12] in WLANs. They discussed cooperation in packet forwarding, which can be also effective but is a different model from ours. Furthermore, most of the conventional cooperation methods in wireless networks including [11] and [12] were discussed only in the link or/and physical layer.

6 Conclusion

We proposed a TCP window-size delegation method for downlink TXOP Exchange in WLANs. In our method, a proxy server lets one station (the TXOP provider) delegate TCP window size to another station (the TXOP client) so that the provider delegates its TXOPs in CSMA/CA to the client. Our method enables an STA to flexibly delegate TXOPs to another STA without adversely affecting the legacy STAs, which is confirmed by computer simulations. We also confirmed that our method requires no modification to legacy APs and STAs and needs only minimal modifications of the TCP functions of the proxy server.

We would like to mention that our method enables N-providers to delegate their window size to M-clients simultaneously, although, in this paper, we consider only a case where a provider delegates its window size to a client. We will observe the case where N-providers delegate their window size to M-clients in the future work. Future work also includes a design of a coordination algorithm that ensures fair incentives for cooperation between STAs.

Declarations

Acknowledgements

This work is supported in part by the National Institute of Information and Communications Technology (NICT), Japan, under Early-concept Grants for Exploratory Research on New-generation Network.

Authors’ Affiliations

(1)
Graduate School of Informatics, Kyoto University, Kyoto, Japan
(2)
Cybermedia Center, Osaka University, Osaka, Japan

References

  1. IEEE Std 802.11e: Medium Access Control (MAC) Quality of Service Enhancement. 2005.Google Scholar
  2. Braden R, Clark D, Shenker S: Integrated Services in the Internet Architecture: An Overview, RFC 1633. 1994.Google Scholar
  3. Blake S, Black D, Carlson M, Davies E, Wang Z, Weiss W: An Architecture for Differentiated Services, IETF RFC 2475. 1998.Google Scholar
  4. Nishio T, Shinkuma R, Takahashi T, Mandayam N: TXOP Exchange: A Cooperative Resource Exchange Method in CSMA/CA. IEICE General Conference, B-15-6, March 2010Google Scholar
  5. Nishio T, Shinkuma R, Takahashi T, Mandayam N: Transmission-Opportunity Exchange for Cooperative Bandwith Allocation in Wireless Local Area Networks. IEICE Technical Report, MoMuC2010-3 2010, 13-18.Google Scholar
  6. Nishio T, Shinkuma R, Takahashi T, Mandayam N: A Coordination Algorithm for N-node Cooperation Problem in Open-Resource Wireless Access Networks. IEICE Communications Society Conference, BS-9-5, Sept 2010Google Scholar
  7. QualNet[http://www.qualnet.com]
  8. Padhye J, Firoiu V, Towsley D, Kurose J: Modeling TCP throughput: a simple model and its empirical validation. Proceedings of ACM SIGCOMM 1998, 303-314.Google Scholar
  9. Guirguis M, Bestavros A, Matta I, Riga N, Diamant G, Zhang Y: Providing soft bandwidth guarantees using elastic TCP-based tunnels. International Symposium on Computers and Communications, Proceedings of ISCC 2004 2004, 760-765.Google Scholar
  10. Valdez J, Guirguis M: Liberating TCP: the free and the stunts. International Conference on Networking, 2008, ICN 2008 2008, 72-77.Google Scholar
  11. Liu P, Tao Z, Narayanan S, Korakis T, Panwar S: CoopMAC: a cooperative MAC for wireless LAN. IEEE J Sel Areas Commun 2007, 25(2):340-354.View ArticleGoogle Scholar
  12. Bahl P, Chandra R, Lee P, Misra V, Padhye J, Rubenstein D, Yu Y: Opportunistic use of client repeaters to improve performance of WLANs. IEEE/ACM Trans Netw 2009, 17(4):1160-1171.View ArticleGoogle Scholar

Copyright

© Nishio et al; licensee Springer. 2011

This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Advertisement