A Reactive Approach to QoS Provisioning in IEEE ...

A Reactive Approach to QoS Provisioning in IEEE 802.11e WLANs Filippo Cacace, Giulio Iannello, Massimo Vellucci, and Luca Vollero Universit`a Campus Bio-Medico di Roma

Abstract—IEEE 802.11e provides basic mechanisms for traffic differentiation in WLANs previously unavailable with the IEEE 802.11 standard. The Enhanced Distributed Channel Access (EDCA) is probably the most promising subset of such mechanisms, and it is already implemented in a huge number of Network Cards. In this paper we present an algorithm for the provisioning of QoS in EDCA WLANs. The algorithm is based on monitoring and reactive configuration of EDCA mechanisms in scenarios where Voice over IP (VoIP) and Best Effort (BE) applications concurrently access the Wireless Channel. Results obtained in a real test-bed prove the effectiveness of the algorithm both in protecting VoIP communications and in providing minimal quality levels and fairness to BE applications. Index Terms—Wireless LANs, QoS provisioning, EDCA.

I. I NTRODUCTION Real time and multimedia communications with Quality of Service (QoS) support are increasingly important in wireless networks of any nature, due to the growing demand of services like VoIP, streaming and videoconferencing and to the network’s limited capacity. They are especially challenging for WLANs based on the IEEE 802.11 protocol due to the distributed and contention-based nature of channel access mechanism currently available in commercial products. The introduction in the IEEE 802.11e standard [1] of a new contention access scheme called Enhanced Distributed Channel Access (EDCA) has provided mechanisms for QoS support which were previously unavailable with the Distributed Coordination Function (DCF) used in the widely deployed 802.11 WLANs. The EDCA is however only a basic mechanism which should be used in the context of a comprehensive approach to implement QoS support. In this paper we present an approach aimed at providing QoS support in IEEE 802.11e networks where real-time (RT) and best effort (BE) sources coexist. Our method is oriented to networks in infrastructure mode and it is based on three components, all running on the Access Point (AP): (i) a monitoring mechanism, (ii) an algorithm for admission control of RT flows, and (iii) an algorithm for the dynamic tuning of the 802.11e MAC parameters. The three components cooperate to attain a wide range of QoS goals (RT admission control, fairness issues between RT and BE traffic, fairness between uplink and downlink flows, etc.) within a unified framework. In particular, the monitoring mechanism provides feedback to the other two components about the effects of their decisions, enabling both an optimistic approach to admission control and dynamic adaptation to changes in the underlying communication system.

Our proposal has several attractive features. First, it can leverage results from previous work on analytical models, but, unlike approaches relying on models only, it does not require precise knowledge of the parameters characterizing the wireless link at both PHY and MAC layer. Second, it is robust both to unexpected or difficult to model workload and to variations of channel conditions. Third, it does not require modifications to the existing protocols and it is easy to implement using available hardware. The rest of the paper is organized as follows: we review the background and related work in Section II. Section III describes the proposed approach. The testbed used in the experiments is introduced in Section IV. Experimental results obtained in different scenarios are commented in Section V. Section VI concludes the paper. II. BACKGROUND AND R ELATED W ORK The IEEE 802.11e standard defines Hybrid Coordination Function (HCF), HCF Controlled Channel Access (HCCA) and HCF contention-based channel access, also known as Enhanced Distributed Channel Access (EDCA). HCCA and EDCA are interoperable channel access methods. HCCA is based on polling, while EDCA is based on a slotted and highly parametric CSMA/CA protocol. The EDCA mechanism has been adopted by the WiFi Alliance in the WMM specifications and it is already commercially available. It defines the concept of Access Category (AC): in order to transmit data, every STA may use up to four ACs, each AC implementing a slotted CSMA/CA algorithm with its own parameter and competing to obtain Transmission Opportunities (TXOPs). In each TXOP stations (STAs) are allowed to transmit one or more data frames. The four ACs within a station represent four priority levels for data transmission. The standard names these levels as: background (BK), best effort (BE), video (VI) and voice (VO). In infrastructure systems, APs announce the configuration of ACs in selected beacon frames. The standard assumes that the AP may use a different set of parameters than that it advertises to STAs. To differentiate the behavior of the ACs, four parameters can be set: the AIFS, which determines the interval during which the medium must be sensed idle before an AC is allowed the transmit, the CWmin and the CWmax , which determine the average duration of the backoff process, and, finally, the TXOP, which specifies the maximum channel occupancy time in the case of a successful access.

2

The statistical mechanism for traffic differentiation introduced by EDCA provides less predictable performance than a reservation-based method and also suffers form network congestion. When the traffic load increases, EDCA cannot provide some QoS guarantees. To cope with the problem of wide deployment of EDCA in realistic scenarios, a number of QoS issues have been considered in the literature: •

•

•

•

Call Admission Control for VoIP traffic [2], [3]. VoIP traffic is inelastic and without an admission control the quality of the conversation would be downgraded for all the wireless stations (STA) in the wireless cell. Protection of RT traffic against BE traffic [2], [4]. QoS guarantees for RT traffic should be jeopardized by sudden surges of BE traffic and/or STAs. Fairness between RT and BE traffic [5], [6]. Differentiation mechanisms can provide QoS guarantees to RT traffic but also starve BE traffic. Fairness between uplink and downlink traffic [7]. Contention-based mechanisms provide each host with the same channel access, but the downlink traffic is transmitted only by the AP, although it is shared among all receiving hosts. Hence, fairness between uplink and downlink traffic is a difficult goal.

Specific solutions have been proposed for all the above issues. However, since their goals are somewhat conflicting, a unified framework is needed to meet all the QoS requirements together. This research area is presently very active and due to space reason we limit ourselves to a few references. The proposals to solve QoS issues in WLANs resort to a variety of methods: (i) analytical models; (ii) measurement based methods; (iii) scheduling algorithms; (iv) dynamic setting of 802.11e MAC parameters. Analytical models have been proposed for IEEE 802.11e [4], [8], [9], but the complexity of the protocol and of the characteristics of real traffic makes these efforts more interesting from a theoretical point of view rather than for deployment in real scenarios. Measurement based techniques [2], [10] define indicators related to the channel occupancy to perform predictions and take decisions about the impact of new flows. The limit of this approach is that the additional overhead due to increased contention is difficult to estimate a priori. Scheduling algorithms approaches propose modifications to the 802.11e MAC protocol [11], [14] or implement custom service differentiators above the MAC layer to pursue the QoS goals [12]. These approaches are flexible, but a common drawback is that they need to be implemented not only at the AP but also on STAs, to regulate uplink traffic. This is a noticeable inconvenient in practical deployments with legacy stations. Dynamic tuning of 802.11e MAC parameters [5], [13], [14] is a powerful technique to achieve QoS guarantees, but there is not yet a generally accepted method for determining the optimal configuration of parameters. An integrated measurement-based scheme for admission of RT traffic and bandwidth sharing control for voice/video/data traffic is presented in [15]. The approach is flexible but difficult to implement and has only

been validated through simulation. A method to enforce fair channel sharing among stations is presented in [12]. A service level manager (SLM) is implemented on top of a scheduling based differentiation algorithm. The approach demonstrates the effectiveness of packet dropping at Layer 3 as a control mechanism for TCP best effort traffic. Nevertheless, method validation is carried out exclusively by simulation and the traffic scenarios are limited to cases where RT traffic is far from saturating the radio link. III. P ROPOSED A PPROACH For the sake of simplicity, we consider here an IEEE 802.11e WLAN with BE and RT symmetric traffic. This assumption however is not critical, and the framework we present in the following could be extended to manage other traffic patterns (e.g. non symmetric RT traffic). Our QoS goals are the following (in descending priority order): 1) RT traffic respects its constraints on delay and loss ratio; 2) BE traffic has a minimum guaranteed bandwidth, equally distributed between uplink and downlink; 3) the maximum number of RT flows compatible with previous constraints must be admitted; 4) the throughput of the wireless channel must be maximized; To fulfill the above goals we propose to use three main software components deployed in the access network: a) WLAN Monitoring (MON): It is the feedback mechanism that detects loss rate, uplink/downlink throughput of RT and BE traffic and RT average delay. It dispatches this information to the other two modules. b) Call Admission Control (CAC): It receives requests of RT flows that originate from, or are addressed to, the STAs. It also receives information about the WLAN status from MON. CAC decides whether to admit (or reject) a new RT flow. After the admission, the RT flow must be protected until its natural conclusion (that is, preemption is not allowed on RT flows). c) MAC setting optimizer (OPT): It decides the best setting of 802.11e MAC parameters to meet the QoS and fairness requirements of RT and BE flows. The MON module extracts data from the NIC’s driver, thus it should be co-located with the AP. The other two modules can be executed by the AP or by another entity such as the Access Controller of a Centralized WLAN. The CAC module has a reactive behavior. Upon a request it enters a probe phase to evaluate the impact of the new flow on the wireless channel status, after which the RT flow is either admitted or rejected. CAC should be integrated with a SIP proxy to receive RT requests from higher layer protocols and communicate admission decisions to the RT flow endpoints. These three modules are executed concurrently. The only synchronization necessary is that OPT must be inactive during a probe phase started by CAC. A. MON Implementation The MON module is the basic building block to control the wireless channel. We have implemented a few simple extensions to the NIC driver used in our test-bed (The MADWIFI

3

STAs. Notice that our estimator can be used on any AC, not only VO, and it does not rely on particular hypotheses about concurrent traffic or flow characteristics. B. CAC Implementation

Fig. 1. Average VoIP downlink delay of 10 STAs and its estimate on the AP as a function of time.

driver1 ) to retrieve statistics about incoming and outgoing packets, bit-rates, retries, queue length, etc. for each AC. This information is reported at fixed time intervals (100 ms if not otherwise specified) to CAC and OPT. A crucial task of the MON module is detecting the delay of the RT traffic. In presence of symmetric RT traffic the AP is the bottleneck, i.e. donwlink delay will always be larger than uplink delay and most of packet loss is due to queue overflows on the AP. It is therefore sufficient to enforce a delay limit on the downlink. Since the number of packets in the queue at the AP is directly related to the congestion of the wireless link, we can use that queue length as an estimate of the downlink delay. More precisely, if in a time interval [t1 , t2 ] the AP sends n packets, the average service delay per packet is necessarily less than ∆t n , being ∆t = t2 − t1 . Let us assume that the length of the sending queue is greater than 0. If l is the amount of dropped packets and ∆q is the difference between the queue lengths in the time interval, qt2 − qt1 , the number of sent packets is equal to: nsent = nin − l − ∆q, where nin is the number of packets arrived in [t1 , t2 ]. The average service ∆t delay per packet is thus less than dserv = nin −l−∆q . If qt is the queue length at time t, for a packet that joins the queue the expected service delay is: d=

qt2 ∆t nin − l − ∆q

This estimate of average downlink delay can be measured at the AP since all the parameters are available at the interface driver. Using the logs provided by the monitoring application, we tested the hypothesis of estimating the service delay from the AP queue length as described above. Figure 1 shows a 150s sample for VoIP flows with interfering BE traffic. The downlink delay (average on 10 STAs) is expressed as a function of time. In this experiment, the delay estimate is computed once per second. Of course, different time granularities can be chosen. The delay fluctuates widely because of the congestion on the channel. The estimate from the queue length on the AP is a good approximation of the delay experimented by the 1 [Online].

Available: http://madwifi.org

The CAC module presented here is rule based and uses a probe phase for a new RT flow. During the probe phase, CAC monitors 4 QoS indicators: d (service delay of the VO AC), qV O (queue length VO AC at the AP), lBE (BE loss ratio) and Tn (average of the last n estimates of BE throughput provided by MON). In our implementation we used 2s for the duration of the probe phase, and n = 5. Since the time interval among estimates is 0.1s, T5 refers to 0.5s of traffic. d, qV O and Tn are compared respectively with a delay threshold dl (we used dl = 50ms), with a queue threshold qV Omax and with TG , the minimum guaranteed bandwidth for BE. The reason to check independently d and qV O is that dl might correspond to a queue larger than the physical size buf size of the sending buffer (usually 50 packets). In this case the congestion could not be promptly detected through the delay computed from the queue size as shown in the previous section. We thus introduce an additional check, setting qV Omax = buf size/2. At the beginning of the probe phase, the current BE throughput T0 is also recorded. A new RT flow is accepted if the following two conditions are always true during the probe phase: • d < dl and qV O < qV Omax ; • Tn > TG or T0 < TG , lBE = 0. The first condition is straightforward. The second condition checks either if the BE throughput is above the minimum threshold or if the offered BE traffic does not saturate the available bandwidth. Whenever one of them fails, the RT flow is rejected. In a realistic scenario, the rejection can be performed through a signaling protocol like SIP. To evaluate the performance of the approach in our test-bed we made the AP disassociate the STA generating the rejected flow. The duration of the CAC probe phase is thus between 0.1 and 2s at most. C. OPT Implementation The OPT module dynamically adapts 802.11e MAC parameters in order to: (i) protect RT QoS from BE traffic; (ii) guarantee BE throughput; (iii) improve aggregate uplink/downlink BE fairness. The structure of the OPT module is shown in Fig. 2. The three conditions correspond to the three goals above and are mutually exclusive. The VO QoS is the most critical and is evaluated first. When the BE traffic is causing problems to the VO traffic, OPT changes the BE AIFS MAC parameter to defend the RT priority. The second condition checks if BE traffic is below the protected bandwidth and it is possible to increase it. In this case, the BE AIFS parameter is modified to restore resources reserved for BE traffic. The third condition detects aggregate uplink/downlink unfairness for the BE traffic. Aggregate means that we do not cope with per-flow or perstation fairness. In this case, OPT uses the BE CWmin MAC

4

•

•

Fig. 2.

Structure of the OPT module

parameter to prioritize the downlink traffic. These strategies have been chosen leveraging the results of previous work on IEEE 802.11e QoS mechanisms [6], [16]. Indeed, the use of the AIFS parameter to defend RT priority allows guaranteed bandwidth at high loads, and that its prioritization effect does not degrade when the number of BE stations is increased. Likewise, we used CWmin to restore fairness between uplink and downlink traffic for two reasons: (i) it does not interfere with the AIFS mechanism used for RT traffic; (ii) for a given CWmin the throughput ratio among STAs is constant when the numbest of STAs is increased: it is therefore easier to mantain a target ratio between uplink and downlink traffic using this parameter. The OPT conditions can be defined in more detail as follows: • VO not QoS. True if d > dl or qV O > qV Omax ; • BE not fair. True if there is VO and BE traffic, TBE < TG , AIF SBE > AIF SV O , and a VoIP flow has terminated after the last execution of manage VO not QoS (see Fig. 2). • up/down not fair. It consists of three different cases with correspondingly different management actions: (i) restore CWminBEup . True if TBEup > 0, TBEdown = 0; (ii) increase downlink. True if TBEup > TBEdown and qBE > qhigh ; (iii) increase uplink. True if TBEup < TBEdown and qBE < qlow . Where qhigh and qlow are two heuristically chosen thresholds for the BE queue. VO not QoS and BE not fair correct opposite situations. To avoid instability, BE not fair evaluates to true only after a change in VoIP flows. For the same reason, cases 2) and 3) above use different thresholds for the length of BE queue on the AP. The throughput comparisons use 90% confidence intervals, computed from the last 10 samples, to account for short-term variability. The management actions corresponding to the above conditions are: • manage VO not QoS. Starting from AIF Smax , find the minimum value of AIF SBE , greater than its current value, given that d < dl and qV O < qV Omax .That is, after correcting the QoS problem of RT traffic, we search for the minimum value of AIF SBE not disturbing the RT

traffic (conditions d < dl and qV O < qV Omax ). manage VO-BE unfairness. Starting from its current value, find the minimum value of AIF SBE , greater or equal than AIF SV O for which conditions d < dl and AIF SBE ≥ AIF SV O hold, and TBE > TG or TBE is maximized given that TBE < TG . That is we search for the minimum value of AIF SBE not disturbing the RT traffic and leading to a throughput, if it exists, not fewer than the guaranteed BE bandwidth. manage up/down unfairness. In the corresponding three cases above: (i) set CWminBEup to its default value; (ii) find the minimum value of CWminBEup , less or equal than the maximum allowed, for which either condition qBE < qhigh or TBEup < TBEdown holds; (iii) find the maximum value of CWminBEup , greater or equal than the default value, for which either condition qBE > qlow or TBEup > TBEdown holds. IV. T ESTBED D ESCRIPTION

To test our approach we have considered different scenarios with RT and BE traffic. We consider an integrated wireless/wireline IP network where access network are comprised of IEEE 802.11e infrastructure WLANs that service wireless hosts (STAs). Real time traffic, appropriately marked through the DSCP field of the IP header, is sent through the IEEE 802.11e VO access category, whereas best effort traffic uses the BE access category, on both the AP and the STAs. Real time traffic is symmetric, i.e. it is composed by two identical flows, one from the mobile station to a host on the wired portion of the network and the other one in the opposite direction. These flows are CBR and the bit rate depends on the codec used. For VoIP, we use the ITU G.711 (64kbps) and G.729 (8kbps) codecs. In the experiments we also consider typical videoconferencing flows at higher bit rates (we used 200 and 400 kbps). Packet size and the number of packets per second (pps) depend on the packetization interval. VoIP applications often make use of silence suppression methods to reduce their bit rate, thus generating VBR flows, but the nominal CBR rate is a meaningful worst-case benchmark. For real-time traffic important parameters are the loss ratio and the total end-to-end delay. The former can be easily deduced from the sequence number contained in the RTP header. A precise evaluation of the latter is more difficult, as it requires a synchronization of the clocks between the two end points. To overcome this difficulty, we have devised a schema where the end points of each real-time flow coincide. In our experimental set-up , each STA has two interfaces, one connected to the wired network and the other to the wireless network through the AP. A VoIP session is composed by two flows, one outgoing from the wireless interface to the AP, then on the wired link end eventually to the Ethernet card of the same STA. The second flow follows the reverse path. A NAT table on the AP is used to change the destination IP address of a pseudo-corresponding node with the IP address of the other network interface of the STA generating the flow. Since the NAT delay can be experimentally shown to be negligible, this

5

set-up eliminates the need for cumbersome synchronization procedures and makes possible a precise measurement of the total end-to-end delay using two timestamps generated by the same clock. The wired network is composed by 100 Mbit Ethernet links connected through switches. Its contribution to the total delay is negligible, thus we may obtain a good estimate of the delay generated by the access network in both directions. A single host, the Corresponding Node (CN), is the end point for sending/receiving interfering BE traffic (either in uplink or in downlink). The hardware components used as STAs and CN are HP tc4200 laptops running Linux Ubuntu OS with kernel 2.6.1526-386, while as AP we used a Compaq/HP Evo N800v laptop running the same OS. The wireless NICs used in the test-bed and implementing WMM extensions are NETGEAR WG511T PCI cards equipped with an Atheros chipset. Vendor specific features are disabled. The MADWiFi 0.9.2.1 open source driver for this card allows to dynamically adjust the MAC parameters (CWmin , CWmax , AIF S and T XOP ) of the four ACs. The AP, the STAs involved in the real time traffic, and the corresponding host for best effort traffic are connected through 100 Mbps Ethernet cabled to two switches. No other traffic was present on the cabled network, and the wireless channel chosen had no interference with other 802.11 sources. The AP and part of the STAs are co-located on a conference table, with the other STAs at a distance of at most 2m from the AP, which minimizes the influence of distance on signal strength and resultant throughput. On the 802.11e interface cards the data rate is set to 11Mbps (fixed rate), QoS parameters of the ACs are initially set as in the standard and 802.11b is used at the physical layer. RTS/CTS and power control are disabled. V. E XPERIMENTAL SCENARIOS 1) VoIP CAC: The first set of experiments aims at evaluating the capability of the CAC module to perform admission control of RT flows. We used G.729, G.711 and 200 kbps CBR codecs. In each experiment, a VoIP STA joins the network every 5s. When the maximum number of STA is reached, we perform two attempts to add an extra STA, that is rejected by CAC. We repeat each experiment three times. We aim at showing that CAC actually admits the correct number of STAs, and that the probe phases do not disrupt the already admitted VoIP conversations. Results are reported in Table I. The admission limit is compared with results obtained with ns2 (third column). In the simulations, we considered a loss rate of 1% as the admission limit. Interestingly, CAC admits 1-2 VoIP flows more. This can be explained as a consequence of physical diversity (as confirmed by the fact the collision probabilities measured in the testbed on the STAs had wide variations) that is not modeled in the simulator. This strengthens our opinion that an adaptive approach can attain better performance than a model. The RT flows duration was 90s on average. Loss rate for the admitted flows is reported in the fifth column of Table I: despite the probe phases, loss ratio was never more than 0.4%

and on average well below 0.1%. The last column lists the duration of the time interval in which the downlink delay was above 50ms due to the probe phase. This value is always below 0.6s; moreover the delay was never more than 100ms. We can thus conclude that the probe phase has no perceivable effect on the ongoing VoIP conversations. As for the duration of the probe phases, the values reported in the fourth column refer to the time interval between the request of the new call and the rejection decision of CAC. This value is around 1s, which is the time needed for the AP queue to build up as an effect of the channel congestion. In a practical deployment, this time interval would correspond to the ring-back of the pending request. The ring-back tone should be sent in-band by the VoIP client or by the SIP proxy to test the channel. 2) VoIP CAC with Interfering Traffic: In this scenario we evaluate the CAC module in presence of BE traffic. As a preliminary test, we measured how throughput of saturated BE traffic decreases when the number of VoIP flows increases. Simulations with ns2 prove that BE Throughput decreases linearly with the number of active VoIP flows. This behavior is general and observable also experimentally on the testbed. Moreover, it is approximately identical for both TCP and UDP flow, and it turns out to be largely independent of the flow direction (downlink or uplink). We then performed a large number of tests aiming at characterizing the behavior of CAC and OPT modules when there is interfering traffic. In all tests, initially, there are a given number of homogeneous BE sources saturating all available bandwidth (about 750 kB/s using standard BE AC configuration). The guaranteed BE throughput was set at 500 kB/s, and as BE traffic we consider UDP-only (up or down), TCP-only (up or down), and UDP and TCP together. There are 1 to 5 saturated BE sources, with a packet size of 1400 bytes. Every 10 s, a new VoIP STA joins the network, and when the first VoIP STA is rejected, no more VoIP requests are issued. The load is then maintained for 30 s before terminating the experiment. Note that, in this case, VoIP STAs are rejected due to constraints on the BE throughput rather than for RT QoS reasons. Representative results are shown in Table II. For each traffic pattern, as main performance indices we evaluate the number of admitted VoIP conversations (2nd column) and the resulting BE throughput after that all admitted VoIP flows have started (6th column). We report also: the duration of the probe phase for the rejected STA (4th column) and its impact on ongoing traffic (5th column, reporting the overall average downlink VoIP loss rate, which is always larger than uplink loss rate). The VoIP delay is not reported but it is always less than 10ms. Finally, in columns 2-3 we compare the number of VoIP STAs admitted by CAC with the result obtained with ns2 under the condition that BE throughput is larger than 500 kB/s. It can be observed that the number of BE sources has a limited impact on the number of admitted VoIP flows. Performance of TCP and UDP are occasionally different. In particular, UDP suffers from a larger packet loss, whereas TCP better adapts to the available bandwidth. With TCP

6

TABLE I A DMISSION OF VO IP

CAC limit 14 12 12 10 10 9 8

A DMISSION OF VO IP

CAC

1 5

4 4

3

7

1 5

2 2

3

4

1

3

1 5

2 2

2,2

3

FLOWS

Block Delay (s) 1.308 ± 0.074 1.408 ± 0.007 0.862 ± 0.311 1.429 ± 0.504 1.292 ± 0.181 0.613 ± 0.035 0.582 ± 0.020

Packet Loss (%) 0.016 ± 0.018 0.070 ± 0.031 0.031 ± 0.017 0.058 ± 0.040 0.093 ± 0.038 0.226 ± 0.064 0.383 ± 0.179

d > 50ms (s) 0.000 ± 0.010 0.021 ± 0.006 0.003 ± 0.005 0.001 ± 0.001 0.537 ± 0.150 0.332 ± 0.068 0.251 ± 0.100

TABLE II BE GUARANTEED THROUGHPUT OF 500 K B/ S

FLOWS WITH A

ns2

Block (s) Pck Loss (%) BE (kB/s) UDPup , G.711@100pps 3 0.572 0.006 ± 0.010 527.8 3 0.604 0.010 ± 0.011 550.5 UDPup , G.711@50pps 6 1.884 0.037 ± 0.022 553.6 TCPup , G.711@100pps 2 1.664 0.024 ± 0.001 548.4 2 0.131 0.000 ± 0.000 604.1 TCPup , G.711@50pps 3 1.652 0.008 ± 0.014 588.8 UDPdown , G.711@100pps 3 0.616 0.000 ± 0.000 520.4 TCPdown , G.711@100pps 2 0.728 0.028 ± 0.028 537.8 2 1.276 0.000 ± 0.000 546.5 TCPdown +UDPup ,G.711@100pps 0.702 0.015 ± 0.012 531.9

the admission limit for VoIP is lower, due to the increased contention on the channel caused by the transmission of the ACKs. 3) Fairness between RT and BE Traffic: In this subsection we evaluate scenarios in which either the RT QoS must be protected against BE traffic, or the BE throughput can be increased. Initially, no BE traffic is present, and the maximum number of VoIP STA is admitted (notice that in absence of BE traffic, CAC only blocks VoIP calls for VO QoS issues). Then, saturated BE sources start. Usually, 802.11e default parameters provide enough differentiation to protect RT QoS, but there are situations where even a single BE flow causes QoS problems to RT traffic. We analyze these cases. OPT reacts to RT QoS problems by adaptively changing AIF SBE as described in Section III-C. To evaluate its effectiveness we compare the VoIP performance with and withrou the OPT module. After steady state is reached, one VoIP flow is terminated, and OPT searches for new MAC parameters to increase the BE throughput, which is under the guaranteed threshold. We analyze here three representative cases of the scenario just described: (i) 8 RT flows (200 kbps @ 80 pps) with one saturated downlink TCP source, (ii) 8 RT flows (200 kbps @ 100 pps) with one saturated downlink TCP source, and (iii) 8 RT flows (400 kbps @ 40 pps) with two downlink TCP and one uplink UDP. In all cases, BE packet size was 1400 bytes. Table III compares the VoIP performance with and without

CAC 4 6 5 4 4 4 4 4 4 4

ns2

Block (s) Pck Loss (%) BE (kB/s) UDPup , G.729@100pps 4 1.582 0.007 ± 0.014 565.7 4 1.128 0.031 ± 0.039 502.1 UDPdown , G.711@50pps 6 0.548 0.027 ± 0.024 532.0 TCPup , G.729@100pps 2 1.492 0.032 ± 0.045 506.8 2 0.584 0.014 ± 0.015 546.0 TCPdown ,G.711@50pps 3 1.144 0.007 ± 0.013 537.4 UDPdown , G.729@100pps 4 1.484 0.044 ± 0.044 508.6 TCPdown , G.729@100pps 2 0.904 0.039 ± 0.055 508.4 2 0.593 0.004 ± 0.007 501.1 TCPdown +UDPup ,G.729@100pps 2.021 0.017 ± 0.029 542.2

25

500 avg AP VO queue length STA BE AIFS VO throughput BE throughput

20

AP queue size and STA AIFS

#BE

ns2 limit 13 10 11 9 10 8 7

450 400 350

15

300 250

10

200

throughput (kB/s)

Codec G.729 @ 80 pps G.729 @ 100 pps G.711 @ 80 pps G.711 @ 100 pps 200 kbps @ 60 pps 200 kbps @ 80 pps 200 kbps @ 100 pps

150 5

100 50

0 0

20

40

60

80

100 Time (ms)

120

140

160

180

0 200

Fig. 3. VoIP (400 kbps @ 40 pps) and BE (2 downlink TCP and 1 uplink UDP source) competing traffic.

OPT. Data concern VoIP flows lasting 200s. As in previous tables, the column d > 50ms gives the duration of the time interval in which the the downlink delay is above 50ms. Notice in particular that, in the third case, VoIP suffers considerable loss and delay if MAC parameters are not updated. Moreover, OPT interventions makes VoIP flows more stable in all cases. To provide additional insights on the OPT working, we analyze in more detail the evolution of VO and BE throughput, AIFS setting and average VO queue length at the AP for the

7

TABLE III VO IP

Description 9x 200 kbps, 1 TCP down 8x 200 kbps, 1 TCP down 8x 400 kbps, TCP+UDP

PERFORMANCE WITH INTERFERING

no adaptation Pck Loss (%) Avg delay (ms) 0.292 ± 0.108 8.3 ± 2.2 0.386 ± 0.083 13.6 ± 2.0 0.896 ± 0.102 50.6 ± 5.4

third case (see Fig. 3). The left y axis refers to both the AIFS value and queue length, whereas the throughput scale is on the right. Initially, VoIP throughput rises when the 8 VoIP STAs join the network. BE sources start transmitting at about t = 53s. Due to the increased contention in a situation already close to saturation, VoIP traffic experiments a growing delay, and more packets are queued in the sending VO queue of the AP. At about t = 66s OPT detects that the queue length is over the guard level, and changes AIF SBE for the STAs from 3 to 7. This modification is broadcast in the AP beacon. Since the AP queue length falls rapidly, but BE throughput is under the guaranteed bandwidth, OPT tries a smaller value, setting AIF SBE = 6. The AP queue now rises again, and OPT determines that 7 is the correct value for the present situation. After OPT intervention, BE throughput is reduced to 70 kB/s, but existing VoIP flows are preserved. At t = 130s, one VoIP flows terminates, and OPT decreases AIF SBE to allow BE throughput to rise at about 180 kB/s. The sudden spikes in the AP queue length when the initial value of AIF SBE = 3 is restored, indicate that the maximum BE throughput compatible with the remaining 7 VoIP flows has been reached. Of course, in this situation no more VoIP calls are admitted, and as soon as active calls terminate the BE throughput increases until the guaranteed BE threshold or the offered load is reached. 4) Fairness between uplink/downlink BE Traffic: We analyze a scenario where BE uplink-downlink fairness issues arise. We consider 2 STAs transmitting an uplink BE flow, and one STA receiving a downlink BE flow. It is well known that with symmetric MAC settings downlink flows are impaired, thus we investigate whether the OPT mechanism based on the CWmin may improve fairness. We distinguish four cases, according to the transport protocol used for uplink and downlink flows: UDP-UDP, TCP-TCP, TCP down and UDP up, UDP down and TCP up. Each experiment lasts 280s. 60s after that BE flows have started, 3 VoIP conversations (G.711 @ 100 pps) begin at 30s intervals. VoIP traffic is used to study the behavior of uplink and downlink flows when the available bandwidth decreases. Afterwards, VoIP flows end, restoring the available bandwidth for the last 60s. Fig. 4 reports the BE throughput (uplink, downlink, and aggregate) for the four different transport protocol combinations. The left-hand plots refer to experiments without OPT, the right-hand ones to experiments with OPT. In the first case the CWBEmin value2 is constant to the default value, whereas 2 Since the 802.11 standard requires that values of CW can be only doubled starting from an initial minimum window, values reported here for CW do actually correspond to the exponent of the power of 2 coefficient used to calculate current CWBE .

d > 50ms 0.49s 0.26s 25.40s

BE TRAFFIC

Pck Loss (%) 0.037 ± 0.019 0.038 ± 0.024 0.018 ± 0.014

OPT Avg delay (ms) 3.2 ± 0.9 4.0 ± 0.5 5.3 ± 0.8

d > 50ms 0.19s 0.12s 0.22s

in the second case is varied by the OPT module. In the UDP-UDP case, OPT maintains a fair share until 120s. The reason for which the CWminBEup is increased after about 120s is probably that the VoIP traffic causes more congestion on the AP than on the STAs, thus impairing BE downlink. There is a transient situation in which downlink throughput is larger than the uplink one, until at 265s the CWminBEup (and the fairness) are restored. Without OPT, the equal channel access opportunities granted to all the stations cause an uplink throughput roughly twice the downlink throughput. Notice also that OPT allows a (slightly) larger aggregate throughput. In the TCP-TCP case, the unfairness is still more evident, since TCP downlink is almost starved by the two TCP uplink flows. OPT corrects the unfairness problem, and also scores a slightly better aggregate throughput by setting CWminBEup to 7. Fairness is also improved in the TCP down-UDP up case, with CWminBEup = 6, even though in this case at the expense of a small reduction in the aggregate throughput. Finally, in the UDP down-TCP up case, without OPT there is a certain variability of the throughput ratio when VoIP flows are started. This probably depends on the increase of the loss of TCP ACKs at the AP when the congestion rises. OPT consistently favors the downlink flow, but in this case it does not reach a complete fairness. The latter case suggests the need of an L3 mechanism to limit UDP downlink flows before they reach the AP. In fact, when UDP rate rises without limits, TCP ACKS are discarded in the BE queue together with UDP packets, causing the starvation of TCP uplink flows. This is a well known phenomenon observed also in other contexts. A traffic shaper for UDP downlink traffic could be usefully integrated with our approach to cope with these extreme situations. As an alternative, BE UDP and TCP could use distinct 802.11e ACs. VI. C ONCLUSIONS The behavior of wireless links is variable and difficult to predict. For this reason many methods for the reliable QoS provision over WLANs can benefit from a monitoring approach that provides them some sort of feedback. We have shown in this paper that it is possible to build a simple and robust reactive control starting from the monitoring of the IEEE 802.11e AP queues. A few items have been left for future work: the extension of the method to account for streaming traffic, the support of legacy 802.11b/g stations, the introduction of proactive monitoring, for example to gather information about the offered uplink BE traffic, that cannot be easily deduced from the AP data, and finally the extension of

8

900

UDP BE (uplink) UDP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

10

1000 900

8

700

6

600 500

BE CWmin

800

4

400 300

700

6

600 500 4

400

2

200 100

100 0

0 50

100

150

200

0

0 0

250

50

100

Time (s)

1000 900

200

250

TCP BE (uplink) TCP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

10

1000 900

8

800 700

6

600 500

BE CWmin

4

400 300

10

8

800 700

6

600 500 4

400 300

2

200

2

200

100

100

0

0 50

100

150

200

250

0 0

50

100

Time (s) 1200

UDP BE (uplink) TCP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100 1000 900

200

250

UDP BE (uplink) TCP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

10

1000 900

8

700

6

600 500

BE CWmin

800

4

400

throghput BE (kB/s)

1200

150 Time (s)

300

10

8

800 700

6

600 500

BE CWmin

0

0

4

400 300

2

200

2

200

100

100

0

0 0

50

100

150

200

0

250

0 0

50

100

Time (s) 1200

TCP BE (uplink) UDP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100 1000 900

200

250

TCP BE (uplink) UDP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

10

1000 900

8

700

6

600 500

BE CWmin

800

4

400 300

throghput BE (kB/s)

1200

150 Time (s)

10

8

800 700

6

600 500

BE CWmin

throghput BE (kB/s)

1200

TCP BE (uplink) TCP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

throghput BE (kB/s)

1200

150 Time (s)

BE CWmin

0

throghput BE (kB/s)

8

800

300 2

200

throghput BE (kB/s)

10

BE CWmin

1000

throghput BE (kB/s)

1200

UDP BE (uplink) UDP BE (downlink) BE (total) VoIP (uplink+donlink) STA BE CWmin

1100

throghput BE (kB/s)

1200

4

400 300

2

200 100

2

200 100

0

0 0

50

100

150

200

250

Time (s)

0

0 0

50

100

150

200

250

Time (s)

Fig. 4. Comparison of uplink and downlink throughput without (left) and with adaptation (right). From top to bottom: (i) 2 UDP up and 1 UDP down STAs; (ii) 2 TCP up and 1 TCP down STAs; (iii) 2 UDP up and 1 TCP down STAs; (iv) 2 TCP up and 1 UDP down STAs.

the control algorithm to improve VO Qos in absence of BE traffic. ACKNOWLEDGMENT This work is partly funded by the 6th Framework Programme, Information Society Technologies, under Contracts no. FP6-IST-038423 (CONTENT), no. FP6-IST-034819 (ONELAB) and no. FP6-IST-033516 (NETQOS). R EFERENCES [1] I. S. 802.11e 2005. IEEE Standard for Information Technology Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Medium Access Control (MAC) Quality of Service Enhancements, 2005. [2] D. Gu, and J. Zhang, “A New Measurement-Based Admission Control Method for IEEE 802.11 Wireless Local Area Networks”, in Proceedings of PIMRC 2003, vol. 3, pp. 2009-2013, September 2003. [3] L. X. Cai, X. Shen, J. W. Mark, L. Cai, and Y. Xiao, “Voice Capacity Analysis of WLAN With Unbalanced Traffic”, in IEEE Trans. on Vehicular Technology, vol. 55, n. 3, May 2006. [4] S. Harsha, A. Kumar, and V. Sharma, “An Analytical Model for the Capacity Estimation of Combined VoIP and TCP File Transfers over EDCA in an IEEE 802.11e WLAN”, in Proceedings of IWQoS 2006, June 2006, pp. 178-187. [5] Y. Tanigawa, J. Kim, H. Tode, K. Murakami, “Proportional Control and Deterministic Protection of QoS in IEEE 802.11e Wireless LAN”, in Proceedings of IWCMC 2006, July 2006. [6] P. Clifford, K. Duffy, J. Foy, D. Leith, and D. Malone, “Modeling 802.11e for data traffic parameter design”, in Proceedings of WiOpt 2006, April 2006, pp. 1-10.

[7] C. Casetti, and C.-F. Chiasserini, “Improving Fairness and Throughput for Voice Traffic in 802.11e EDCA”, in Proceedings of PIMRC 2004, 5-8 September 2004. [8] J. W. Robinson, T. S. Randhawa, “Saturation Throughput Analysis of IEEE 802.11e Enhanced Distributed Coordination Function”, IEEE J. Sel. Areas Commun., vol. 22, n. 5, pp. 917-928, June 2004. [9] A. Banchs, and L. Vollero, “Throughput analysis and optimal configuration of 802.11e EDCA”, Computer Networks, vol. 50, (2006), pp. 1749-1768. [10] H. Zhai, X. Chen, Y. Fang, “A call admission and rate control scheme for multimedia supoprt over IEEE 802.11e wireless LANs”, ACM Wireless Networks, vol. 12, n. 4, pp. 451-463, August 2006. [11] Y. Fan, C. Huang, and Y. Tseng, “Multimedia Services in IEEE 802.11e WLAN Systems”, Proceedings of IWCMC 06, July 2006, pp. 401-405. [12] E.-C. Park, D.-Y. Kim, C.-H. Choi, and J. So, “Improving Quality of Service and Assuring Fairness in WLAN Access Networks”, IEEE Transactions on Mobile Computing, vol. 6, n. 4, pp. 337-350, April 2007. [13] J. Freitag, N.L.S. da Fonseca, J.F. de Rezende, J.F., “Tuning of 802.11e network parameters”, IEEE Communications Letters, vol. 10, n. 8, August 2006 [14] A. Banchs, and X. Perez, “Providing Throughput Guarantees in IEEE 802.11 Wireless LAN”, in Proceedings of WCNC 2002, Orlando, FL, March 2002. [15] Y. Xiao, F. H. Li, and B. Li, “Bandwidth Sharing Schemes for Multimedia Traffic in the IEEE 802.11e Contention-Based WLANs”, IEEE Transactions on Mobile Computing, vol. 6, n. 7, pp. 815-831, July 2007. [16] G. Bianchi, I. Tinnirello, and L. Scalia “Understanding 802.11e contention-based prioritization mechanisms and their coexistence with legacy 802.11 stations”, IEEE Network, vol. 19, n. 4, pp. 28-34, April 2005.