# QoS Support for IEEE 802.11 Wireless LAN

Qiang Ni, Thierry Turletti

► To cite this version:

Qiang Ni, Thierry Turletti. QoS Support for IEEE 802.11 Wireless LAN. Wireless LANs & Bluetooth, 4, Nova Science Publishers Inc (Verlag), 2005, ISBN 1-59454-432-8. hal-04649907

HAL Id: hal-04649907

https://inria.hal.science/hal-04649907v1

Submitted on 16 Jul 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
QoS Support for IEEE 802.11 Wireless LAN

Qiang Ni and Thierry Turletti

PLANETE Group, INRJASophia Antipolis

In today's Internet, the emerging widespread use of real-time voice, audio, and video applications makes Quality of service (QoS) a key problem. Meanwhile, the Internet is getting heterogeneous due to the explosive evolution of wireless networks. QoS support in wireless networks is more challenging than in the wired networks since bandwidth is scarce, latency and bit error rate are high and characteristics of the wireless channel vary over time and space. The IEEE 802.11 standard is the most widely deployed wireless local area network (WLAN) infrastructure. However, it cannot provide QoS support for the increasing number of multimedia applications. Thus, a lot of research works have been carried out to enhance the QoS support in 802.11 networks. Recently, the IEEE working group has been working on a new QoS-enhanced standard, called IEEE 802.11e. This chapter describes all these research and standardization activities. We also show through simulations the performance limitations of the upcoming 802.11e standard and discuss several adaptive mechanisms to enhance the performance of the upcoming 802.11e standard.

Adaptive Enhanced Distributed Coordination Access (AEDCA), Fair Hybrid Coordination Function (FHCF), Hybrid Coordination Function (HCF), IEEE 802.11, IEEE 802.11e, Medium Access Control (MAC), Quality of Service (QoS), Service Differentiation.

# I. INTRODUCTION

In the recent past, IEEE 802.11 wireless LAN (WLAN) has emerged as one prevailing wireless technology throughout the world and will also play an important role in the future fourth-generation wireless and mobile communication systems. While 802.11 technology provides a cheap and flexible wireless access capability, it is very easy to deploy an 802.11 WLAN in offices, hospitals, campuses, airports, stock markets, etc. On the other hand, the number of multimedia applications have increased tremendously: people are willing to acquire voice, audio, and high-speed video services even when they are moving. However, multimedia applications require some quality of service (QoS) support such as guaranteed bandwidth, bounded delay and jitter. Providing such QoS support in 802.11 is challenging since the current 802.11 standard does not take QoS support into account<sup>10,20</sup>: both the 802.11 medium access control (MAC) layer and the physical (PHY) layer are designed for best-effort data transmission. Considering that the MAC layer is essential for QoS support, a lot of research efforts have been carried out for the 802.11 MAC. This chapter will review these QoS enhancement research efforts and standardization activities. We also show through simulation results the performance limitations of the upcoming QoS-enhanced IEEE standard named 802.11e. Moreover, several adaptive mechanisms to enhance the QoS performance of this upcoming standard are discussed.

The following section (§2) provides a brief overview of IEEE 802.11 WLAN. Section §3 illustrates the problems of QoS support in the original 802.11 MAC layer. The research efforts and standardization activities on QoS enhancements for 802.11 are addressed in Section §4. Section §5 presents simulation evaluations of the IEEE 802.11e and discusses several adaptive mechanisms to enhance its QoS performance.
## II. OVERVIEW OF 802.11 NETWORKS

### A. The IEEE 802.11 standard family

The IEEE 802.11 WLAN standard covers both the MAC sub-layer and the PHY layer of the open system interconnection (OSI) network reference model¹⁰. The logical link control (LLC) sub-layer is specified in the IEEE 802.2 standard. This architecture provides a transparent interface to the higher layer users: stations may move, roam through an 802.11 WLAN and still appear as stationary to the 802.2 LLC sub-layer and above. This allows existing TCP/IP protocols to run over IEEE 802.11 WLAN just like wired Ethernet. Figure 1 shows a snapshot of IEEE standardization activities done for 802.11 PHY and MAC layers: In 1997, IEEE provided three kinds of options in the PHY layer, which are an infrared (IR) baseband PHY, a frequency hopping spread spectrum (FHSS) radio and a direct sequence spread spectrum (DSSS) radio. All these options support both 1 and 2Mbps PHY rates. In 1999, the IEEE has defined two high rate extensions: (1) 802.11b based on DSSS technology, with data rates up to 11Mbps in the 2.4GHz band, and (2) 802.11a, based on orthogonal frequency division multiplexing (OFDM) technology, with data rates up to 54Mbps in the 5GHz band. In 2003, the 802.11g standard that extends 802.11b PHY layer to support data rates up to 54Mbps in the 2.4GHz band has been finalized. In parallel, several other 802.11 standardization activities are ongoing: 802.11h aims to enhance 802.11a with adding indoor and outdoor license regulations for the 5GHz band in Europe. The 802.11n is a new task group which proposes a high-throughput amendment to the 802.11 standard. The 802.11n will support at least 100Mbps rate, as measured at the interface between MAC and higher layers. It may choose multiple-input multiple-output (MIMO) antenna and adaptive OFDM as main PHY technologies. At the MAC layer, 802.11e will define extensions to enhance the QoS performance of 802.11 WLAN. The 802.11f will propose an Inter-Access Point protocol to allow stations roaming between multi-vendor access points. The 802.11i will propose enhanced security and authentication mechanisms for 802.11 MAC.

<figure><img src="image_2.png" /><figcaption>FIG. 1: Snapshot of 802.11 PHY (left) and MAC (right) standardization activities</figcaption></figure>
## B. IEEE 802.11 MAC layer

The 802.11 MAC layer aims to provide access control functions to the wireless medium such as access coordination, addressing or frame check sequence generation. Two different classes of wireless configuration have been defined for 802.11. An *Infrastructure Network*, where many stations can communicate with the wired backbone through an access point (AP), and the *Ad Hoc Network*, where any device can communicate directly with other devices, without any connectivity to the wired backbone. A group of stations coordinated by 802.11 MAC functions is called a basic service set (BSS) in *infrastructure mode* and independent BSS (IBSS) in *ad-hoc mode*, respectively. The area covered by the BSS is known as the basic service area (BSA), which is similar to a cell in a cellular mobile network.

The IEEE 802.11 MAC sub-layer defines two medium access coordination functions, the basic Distributed Coordination Function (DCF) and the optional Point Coordination Function (PCF)¹⁰.

### DCF: Distributed Coordination Function

<figure><img src="image_3.png" /><figcaption>FIG. 2: DCF access mechanism: CSMA/CA (up) and RTS/CTS scheme (down)</figcaption></figure>

DCF is an asynchronous transmission mode based on Carrier Sense Multiple Access with Collision Avoidance scheme (CSMA/CA). Due to the significant difference between transmitted and received power levels, collision detection can not be implemented. Actually, two different carrier sensing mechanisms are used: PHY carrier sensing at the air interface and virtual carrier sensing at the MAC layer. PHY carrier sensing detects the presence of other STAs by analyzing all packets received from other STAs. Virtual carrier sensing is optionally used by a station to inform all other stations in the same BSS or IBSS how long the channel will be reserved for its frame transmission. To avoid this scenario, the sender can set a duration field in the MAC header of data frames, or in the RequestToSend (RTS) and ClearToSend (CTS) control frames. Then, other stations will update their local timers of network allocation vectors (NAVs) to take into account this duration. As shown in Figure 2, if a packet arrives at an empty queue and if the medium has been found idle for an interval
of time longer than a distributed interframe space called DIFS, the source station can transmit the packet immediately. Meanwhile, other stations defer their transmissions by adjusting their NAVs, and start the backoff process. More precisely, stations compute a random time interval, called *backoff timer*, selected from the contention window (*CW*): *backoff timer* = *rand*[0, *CW*]·*slot time*, where *CW*<sub>min</sub> < *CW* < *CW*<sub>max</sub> and *slot time* depends on the PHY layer type. The *backoff timer* parameter is decreased only when the medium is idle; it is frozen when another station is transmitting. Each time the medium becomes idle, stations wait for a DIFS and continuously decrement their *backoff timer*. Once the backoff timer expires, the station is authorized to access the medium. Collisions occur when at least two stations start transmission simultaneously. On this purpose, a positive acknowledgement (ACK) is used to notify the sender that the transmitted frame has been successfully received, see Figure 2. If the ACK is not received, the sender assumes that there is a collision, and it schedules a retransmission by entering the backoff process again. To reduce the probability of collisions, after each unsuccessful transmission attempt, the *CW* value is doubled until a predefined maximum value *CW*<sub>max</sub> is reached. After each successful transmission, the *CW* is reset to a fixed minimum value *CW*<sub>min</sub>.

Hidden terminals can also induce collisions. These terminals are stations that the receiver can hear but that cannot be detected by other senders. Consequently, frames sent from different senders will collide at the same receiver. To solve this problem, the RTS/CTS scheme can optionally be used: the source sends a short RTS frame before each data frame transmission, see Figure 2, and the receiver replies with a CTS frame if it is ready to receive. Once the source receives the CTS frame, it transmits a frame. All other stations hearing a RTS, a CTS, or a data frame in the BSS update their NAVs, and will not start transmissions before the updated NAV timers reach zero. The RTS/CTS scheme improves significantly the performance of the basic DCF scheme when data frame sizes are large. DCF is mandatory in the standard and can be used both in ad-hoc and infrastructure modes.

PCF: Point Coordination Function

Priority-based access can also be used to access the medium. For example, PCF is a synchronous
service that implements a polling-based contention-free access scheme. It can be used with the
infrastructure mode only. Unlike DCF, its implementation is not mandatory. The reason is that
the hardware implementation of PCF was thought to be too complex at the time the standard was
finalized. Furthermore, PCF itself relies on the asynchronous service provided by DCF and the
beacon interval must allow at least one DCF data frame to be transmitted during the CP. PCF uses
a centralized polling scheme, which uses the AP as a point coordinator (PC). When a BSS is set up
with PCF-enabled, the channel access time is divided into periodic intervals named beacon intervals,
see Figure 3. The beacon interval is composed of a contention-free period (CFP) and a contention
period (CP). During the CFP, the PC maintains a list of registered stations and polls each of them
according to the list. When a station is polled, it starts to transmit data frames, where the size
of each data frame is bounded by the maximum MAC service data unit size. Assuming that the
PHY rate of every station is fixed, the maximum CFP duration for all the stations, which is called
*CFP\_max\_duration*, is then decided by the PC. However, the link-adaptation (multi-rate support)
capability makes the transmission time of a frame variable and may induce large delay jitters, which
reduces the QoS performance of PCF (see Section §3.2). The time used by the PC to generate beacon
frames is called target beacon transmission time (TBTT). The next TBTT is announced within the
beacon frame by the PC to inform all other stations in the BSS. To give PCF higher priority of access
than DCF in a beacon interval, the PC waits for a shorter interframe space than DIFS (called PIFS
standing for PCF interframe space), before starting the PCF. But PCF is not allowed to interrupt
any ongoing frame transmissions in DCF. Then, all other stations set their NAVs to the values of
*CFP\_max\_duration*, or the remaining duration of CFP in case of delayed beacon. A typical medium
access sequence during PCF is shown in Figure 3.

<figure><img src="image_4.png" /><figcaption>FIG. 3: PCF and DCF cycles</figcaption></figure>

Once PCF obtains access to the wireless medium, SIFS timing is used for frames exchanges during CFP except if the polled station does not respond the PC within a PIFS period. When a PC polls a station, it can piggyback the data frames to the station together with the CF-Poll, then the station sends back a data frame piggybacked with an ACK after a SIFS interval. When the PC polls the next station, it piggybacks not only the data frame to the destination, but also the ACK corresponding to the previous successful transmission. Silent stations are removed from the polling list after several periods and may be polled again at the beginning of the next CFP. Note that at any time, the PC can decide to terminate the CFP by transmitting a CF-End frame. Usually, PCF uses a round-robin scheduler to poll each station sequentially in the order of the polling list, but priority-based polling mechanisms can also be used if different QoS levels are requested by different stations.

### III. QOS LIMITATIONS OF 802.11 WLANS

Maintaining QoS is one of the most challenging functions a MAC layer should support. In particular, wireless links have specific characteristics such as high loss rates, bursts of frame loss, high latency and jitter. Furthermore, wireless link characteristics vary over time and location. There are several ways to characterize QoS in WLANs such as parameterized or prioritized QoS as proposed in¹². Generally, QoS is the ability of a network element (such as an application, a host or a router) to provide some levels of assurance for consistent network data delivery. Parameterized QoS is a strict QoS requirement that is expressed in terms of quantitative values, such as data rate, delay bound, and jitter bound. In a traffic specification (TSPEC), these values are expected to be met within the MAC data service in the transfer of data frames between peer stations. Prioritized QoS is expressed in terms of relative delivery priority, which is to be used within the MAC data service in the transfer of data frames between peer stations. With a prioritized QoS scheme, the values of QoS parameters such as data rate, delay bound, and jitter bound, can vary during the transfer of data frames, without renegotiating the TSPEC between the station and the AP. According to the above definitions of QoS, this section presents the QoS limitations of IEEE 802.11 MAC functions.
A. Limitations of DCF

DCF does not support any QoS guarantees, only a best-effort service is provided. Typically, time-bounded applications such as Voice over IP (VoIP), or videoconferencing require specified bandwidth, low delay and jitter, but can tolerate some losses. The point is that in DCF, all the stations compete for the channel with the same priorities. There is no differentiation mechanism to guarantee bandwidth, packet delay and jitter for high-priority multimedia flows. To illustrate the problem, we have made the following simulation using the ns-2²² simulator. A variable number of stations are located within the same IBSS, they use the ad-hoc mode and all hear each other (1-hop distance). Moreover, there is no mobility in the system. Each station uses the IEEE 802.11a PHY transmission mode-6¹¹ and transmits three types of traffic (audio, video, and background flows) to each other. The audio packet size is equal to 160 bytes and the inter-packet arrival interval is 20ms, which corresponds to 8KBytes/s PCM audio flow. The video transmission rate is 80KBytes/s with a packet size equal to 1280 Bytes. The background transmission rate is 128 KBytes/s, and the corresponding packet size is 1600 bytes. The RTS/CTS option is not used. The main simulation parameters are summarized in Table I, the three types of flows use CBR/UDP ns sources. We vary the load rate from 9.6% to 90% by increasing the number of stations from 2 to 18. Figure 4 shows the simulation results for the throughput and delay.

<table><caption>TABLE I: Simulation parameters for 802.11a mode 6</caption><tr><td>SIFS</td><td>16μs</td><td>MAC header</td><td>28Bytes</td></tr><tr><td>DIFS</td><td>34μs</td><td>PLCP header length</td><td>4μs</td></tr><tr><td>ACK size</td><td>14Bytes</td><td>Preamble length</td><td>20μs</td></tr><tr><td>PHY rate</td><td>36Mbps</td><td>CW<sub>min</sub></td><td>15</td></tr><tr><td>slot time</td><td>9μs</td><td>CW<sub>max</sub></td><td>1023</td></tr></table>

<figure><img src="image_5.png" /><figcaption>FIG. 4: Throughput (left) and delay (right) performance for DCF</figcaption></figure>
We can observe that the average throughput of the three flows for a station is quasi-stable when the channel load rate is less than 70% (i.e. the number of stations is up to 10): the mean throughput of audio, video and background is about 7.8 KBytes/s, 80KBytes/s, and 125KBytes/s respectively; and the delay is lower than 4ms. When the number of stations is larger than 10, the throughput of all three flows decrease very fast: it is reduced by 40% when the number of stations is 18 (corresponding to 90% load). Moreover, the mean delays are almost the same for the three flows and increase up to 420ms. This simulation clearly shows that there is neither throughput nor delay differentiation between the different flows. The reason is that these three flows share the same queue, thus they all experience the same delay. Unless admission control is used, there is no way to guarantee the QoS requirements for high-priority audio and video traffic in DCF.

## B. Limitations of PCF

Although PCF has been designed to support time-bounded multimedia applications, this mode has three main problems that lead to poor QoS performance$^{16,18,27}$. First, the central polling scheme is questionable. All the communications between two stations in the same BSS have to go through the AP. Thus, when this kind of traffic increases, a lot of channel resources are wasted. Second, the cooperation between CP and CFP modes may lead to unpredictable beacon delays$^{18,27}$: the AP schedules the next beacon transmission at next TBTT but it has to contend to access the channel, the beacon can then be transmitted when the medium has been found idle for an interval of time longer than a PIFS. Hence, depending on whether the wireless medium is idle or busy around the TBTT, the beacon frame may be delayed. In the current 802.11 legacy standard, stations are allowed to transmit even if the frame transmission cannot terminate before the upcoming TBTT$^{10}$. The duration of the beacon to be sent after the TBTT defers the transmission of data frames during CFP, which may severely impact the QoS performance of multimedia applications. In the worst case, the maximum delay of a beacon frame can be 4.9 ms in 802.11a, and the average delay of a beacon frame can reach up to 250 µs$^{18}$. Third, it is difficult to predict the transmission time of a polled station. A polled station is allowed to send a frame of any length between 0 and 2304 Bytes (the maximum MAC service data unit size), which may introduce variable transmission time. Furthermore, the PHY rate of the polled station can change according to the varying characteristics of the channel, so the AP is not able to predict in a precise manner the transmission time. This prevents the AP to provide guaranteed delay and jitter performance for other stations present in the polling list during the rest of the CFP.

## IV. QOS ENHANCEMENTS FOR 802.11 WLANS

All the limitations for DCF and PCF we have described in the previous section can explain why so many research activities have been launched to enhance the performance of 802.11 MAC. When the bandwidth is not scarce, such as in wired LANs, QoS issues are not so important (1Gbps is now a common link speed in company LANs while 10Gbps 802.3ae Ethernet will appear soon). However, a WLAN have a higher bit error rate, a higher delay and a lower bandwidth than a wired LAN. Thus, they have been originally designed for best-effort, low data rate applications. Characteristics of wireless channels make high data rate transmission very difficult to achieve: The bit error rate (BER) is more than three orders of magnitude larger than in wired LANs. Moreover, high collision rate provoking frequent retransmissions cause unpredictable delays and jitters, which degrade the quality of real-time voice and video transmission. Enhanced QoS-aware MAC aims to reduce overhead, prioritize frames, and limit collisions to meet delay and jitter requirements. Different kinds of QoS enhancement schemes for both infrastructure and ad-hoc modes have been proposed
for 802.11. First of all, QoS enhancement can be supported by adding service differentiation into
the MAC layer. This can be achieved by modifying the parameters that define how a station or a
flow should access the wireless medium. Current service differentiation based schemes can be clas-
sified with respect to a multitude of characteristics. A possible classification criterion is whether the
schemes provide only one priority for one station (we refer to *station-based*) or introduce multiple
priority queues in each station (refer to *queue-based*). Another classification depends on whether
they are *DCF-based* or *PCF-based* enhancements. Figure 5 shows a classification in two levels. We
distinguish between station-based and queue-based schemes at the top-level and DCF-based versus
PCF-based enhancement at the second level. Previous research works mainly focus on the station-
based DCF enhancement schemes¹, ⁴, ²⁴, ²⁵, ²⁶. Other recent works, including efforts done within
the IEEE 802.11e task group, focus on queue-based hybrid coordination (combined PCF and DCF)
enhancement schemes², ⁹, ¹², ¹⁷, ¹⁸, ²⁰, ²³.

<figure><img src="image_6.png" /><figcaption>FIG. 5: Classification of QoS enhancement schemes</figcaption></figure>

A. Station-based QoS enhancement schemes

We will use the classification shown above to present the main QoS enhancement schemes pro-
posed in the literature. In the case schemes have no specific names, we have labelled them using
initials of their respective authors.
# 1. DCF-based schemes

## The IACC scheme

The IACC scheme¹ aims to introduce priorities in the IEEE 802.11 standard under the DCF access method. Three techniques are used: the first one assigns different contention windows to stations with different priorities. Experiments show that this scheme performs well with UDP traffic while it performs badly with TCP traffic. The reason is that all TCP ACKs are sent with the same priorities, which affects the differentiation mechanism. In the second technique, each station sets the DIFS parameter according to its priority level. The main problem of this scheme is that low priority traffic suffers as long as high priority frames are queued. Contrary to the first scheme, there is no backoff problem with TCP, but TCP ACKs also reduce the effects of service differentiation because all ACKs have the same priorities. With the third technique, each station is assigned a different maximum frame length according to its priority level, therefore, a high priority station can transmit more information per medium access than low priority stations. This mechanism is used to increase both transmission reliability and differentiation, and works well for TCP and UDP flows. However, in a noisy environment, long packets are more likely to be corrupted than short ones, which decreases the efficiency of service differentiation.

## The Blackburst scheme

Blackburst²⁴ aims to minimize the delay of real-time traffic. Unlike other schemes, it imposes certain requirements on high priority stations: (1) the use of equal and constant intervals to access the medium, and (2) the ability to jam the medium for a period of time. When a high priority station wants to send a frame, it senses the medium. If it is idle, it sends its frame after a PIFS interval of time; if the medium is busy, it waits for the medium to be idle for another PIFS and then enters a black burst contention period in which the station sends a so-called black burst to jam the channel. The length of the black burst is determined by the time the station has waited to access the medium, and is calculated as a number of black slots. This has the nice effect that real-time flows will synchronize, and share the medium in a time division multiple access (TDMA) fashion. Simulation results show that Blackburst can support more real-time nodes than CSMA/CA, with stable data and real-time traffic operation, due to the absence of collisions. The main drawback of Blackburst is that it requires constant access intervals for high-priority traffic, otherwise the performance degrades considerably.

## The JDRC scheme

The JDRC scheme⁴ is a service differentiation scheme which requires minimal modifications of the basic 802.11 DCF. It uses two parameters of the 802.11 MAC, IFSs and random backoff time between each data transmission to provide the service differentiation: two different backoff time algorithms are combined with two different IFS lengths PIFS and DIFS. Thus, four classes of priorities can be supported. A station that uses PIFS and short backoff time algorithm gets the highest priority, where a station that uses DIFS and long backoff time algorithm obtains the lowest priority. Using the JDRC scheme, high priority stations have short waiting time when accessing the medium. When a collision occurs, high priority stations have more chances to access the medium than the low priority ones. On the other hand, when none of the high priority stations wants to transmit packets, low priority stations still use long backoff time. Thus, an additional delay is imposed by
long backoff time.

### The DFS scheme

The distributed fair scheduling (DFS) scheme<sup>25</sup> utilizes the ideas of self-clocked fair queueing (SCFQ)<sup>8</sup> to introduce both priority and fairness in the wireless domain. In DFS, the backoff process is always initiated before transmitting a frame. Contrary to 802.11 DCF, the backoff interval is computed as a function of packet size and weight of the station, which can be linear, exponential, or square-root function. With this scheme, stations with low weights generate longer backoff intervals than those with high weights, thus get low priority. Fairness is achieved by considering the packet size in the calculation of the backoff interval, causing flows with smaller packet size to be sent more often. If a collision occurs, a new backoff interval is calculated using the original backoff algorithm of the IEEE 802.11 DCF. However, the high complexity implementation of this scheme limits its deployment.

### The VMAC scheme

The virtual MAC (VMAC) scheme<sup>26</sup> uses a distributed service quality estimation, radio monitoring, and admission control mechanisms to support service differentiation. It monitors the radio channel and estimates locally MAC level statistics related to service quality such as delay, jitter, packet collision, and packet loss. The VMAC algorithm operates in parallel to the MAC within a station but it does not handle real packet transmission like the MAC. This is why it is called virtual MAC. The virtual source (VS) algorithm can utilize the VMAC to estimate application-level service quality. This allows application parameters to be tuned in response to dynamic channel conditions based on “virtual delay curves”. VMAC is based on DCF, but uses different $CW_{min}$ and $CW_{max}$ values to support service differentiation. Simulation results show that: (1) when these distributed virtual algorithms are applied to the admission control of the radio channel, then a globally stable state can be maintained without the need for complex centralized radio resource management; (2) delay differentiation can be increased by increasing the gap between $CW_{min}^{high\_pri}$ and $CW_{max}^{low\_pri}$. The main drawback of this scheme is the high complexity introduced to allow interactions between the application and the MAC layers.

## 2. PCF-based schemes

Because PCF is optional in the 802.11 standard, only a few research works focused on PCF enhancements to transmit multimedia flows and the three main problems of PCF (as mentioned in §3.2) have not been solved.

### The priority-based PCF scheme

In PCF, the AP sends priority-based polling packets to a succession of stations in the wireless BSS, which can assign stations different priorities. IEEE 802.11 does not specify how the AP determines the polling sequence. In<sup>28</sup>, four different polling schemes are evaluated to provide service differentiation support in PCF: Round-Robin (RR), First-In-First-Out (FIFO), Priority, and Priority-Effort Limited Fair (ELF)<sup>5</sup>. Simulations show that all these schemes have better performance than DCF.
and can support real-time traffic in some cases. The FIFO scheme achieves the highest throughput although some traffic behave badly. The priority scheme can support at low cost QoS of traffic but may severely affect low priority and best-effort traffic to compensate the losses of high priority traffic. The Priority-ELF scheme is fairer than other schemes and achieves high utilization of the wireless channel link.

### The Robust SuperPoll scheme

The Robust SuperPoll protocol<sup>7</sup> aims to improve performance of the PCF access scheme. Actually, PCF is very sensitive to lost polls. Instead of polling individually stations as in PCF, the SuperPoll mechanism sends polls (called “SuperPolls”) to a group of stations. To make the scheme more robust against frame loss, each packet includes identities of remaining stations to be polled in the list. Therefore, stations have multiple opportunities to receive the poll. The observed increase in bandwidth and decrease in channel access time provide a better support for multimedia applications, especially in noisy environments.

## B. Queue-based QoS enhancement schemes

In order to provide queue-based QoS support, IEEE 802.11e proposed a new MAC layer coordination function called HCF (Hybrid Coordination Function). HCF uses a contention-based channel access method, also called the enhanced distributed channel access (EDCA), that operates concurrently with an HCF controlled channel access (HCCA) method. In HCF, contention-based EDCA and polling-based HCCA are no longer separated, and EDCA is defined as a part of HCF. The AP and stations that implement the QoS facilities are called QAP (QoS-enhanced AP) and QSTAs (QoS-enhanced stations) respectively.

One main new feature of HCF is the concept of transmission opportunity (*TXOP*), which refers to an instance during which a given QSTA has the right to send data frames. The aim of introducing *TXOP* is to limit the time interval during which a QSTA is allowed to transmit frames. Thus, the problem of unpredictable transmission time of a polled station in PCF (as mentioned in Section §3.2) is solved. A *TXOP* is called either *EDCA TXOP*, when it is obtained by winning a successful EDCA contention; or *HCCA TXOP*, when it is obtained by receiving a QoS CF-poll frame from the QAP. In order to limit delay, the maximum value of a *TXOP* is bounded by a value, namely *TXOPLimit*, which is determined by the QAP. A QSTA can transmit packets as long as its *TXOPLimit* has not expired. QAP allocates an uplink *TXOP* to a QSTA by sending a QoS CF-Poll frame, while no specific control frame is required for the downlink *TXOP*. In this subsection, we will describe queue-based 802.11e HCF (EDCA/HCCA) and some enhanced schemes, such as AEDCA, FHCF and SETT-EDD respectively.

### 1. DCF-based schemes

#### The EDCA scheme

EDCA is designed to provide prioritized QoS by enhancing DCF. Before entering the MAC layer, each data packet received from higher layers is assigned a specific user priority value. How to tag such a priority value for each packet is an implementation issue. At the MAC layer, EDCA introduces 4 different FIFO queues, namely, access categories (ACs). As specified in the 802.11e
<table><caption>TABLE II: Mapping between user priorities and Access Categories (ACs)</caption><thead><tr><td>user priorities</td><td>ACs</td><td>Designation</td></tr></thead><tbody><tr><td>1</td><td>AC_BK</td><td>Background</td></tr><tr><td>2</td><td>AC_BK</td><td>Background</td></tr><tr><td>0</td><td>AC_BE</td><td>Best Effort</td></tr><tr><td>3</td><td>AC_VI</td><td>Video</td></tr><tr><td>4</td><td>AC_VI</td><td>Video</td></tr><tr><td>5</td><td>AC_VI</td><td>Video</td></tr><tr><td>6</td><td>AC_VO</td><td>Voice</td></tr><tr><td>7</td><td>AC_VO</td><td>Voice</td></tr></tbody></table>

draft¹², each data packet from higher layers along with a specific user priority value should be mapped into a corresponding AC using a mapping table¹². The user priority value is defined in the IEEE 802.1d bridge specification¹³. As shown in Table II, different kinds of applications such as background traffic, best-effort traffic, video traffic and voice traffic¹³ can be mapped to different AC queues (i.e. AC_BK, AC_BE, AC_VI, AC_VO respectively). Every AC behaves as a single DCF contending entity and each entity has its own contention parameters ($CW_{max}[AC]$, $CW_{min}[AC]$, AIFS[AC] and TXOPLimit[AC]) which are announced by the QAP periodically via beacon frames. Basically, the smaller values of $CW_{max}[AC]$, $CW_{min}[AC]$, AIFS[AC] and TXOPLimit[AC], the shorter channel access delay for the corresponding AC, and thus the higher priority to access the medium. Different from most station-based schemes which only use DIFS and PIFS for differentiation, EDCA introduces a new type of IFS, called arbitrary IFS (AIFS). Each AIFS is an IFS interval with arbitrary length (Figure 6) and is determined by

$$AIFS[AC] = SIFS + AIFSN[AC] \cdot slot \ time,$$

where AIFSN[AC], called the arbitration inter frame space number, represents the number of slot time for an AC. For example, DCF uses AIFSN = 2 to compute DIFS (i.e. DIFS = SIFS + 2 · slot time, see Figure 6). The default EDCA parameters used by QSTAs are suggested in Table III¹². After waiting for an idle time interval of AIFS[AC], each AC has to wait for a random backoff time ($CW_{min}[AC] \le$ backoff time $\le CW_{max}[AC]$). The purpose of using different contention parameters for different queues is to give low-priority traffic a longer backoff time than high-priority traffic. High-priority traffic is likely to access to the medium earlier than low-priority traffic. A potential problem is that the backoff times of different ACs overlap and reduce the effect of service differentiation. Furthermore, in EDCA, backoff timers of different ACs in one QSTA are random values and may reach zero at the same time, thus causing internal collisions. In order to avoid those internal collisions, EDCA introduces a scheduler inside every QSTA to allow only the highest priority AC to transmit a packet. As a result, EDCA aims to support prioritized QoS for multimedia applications.

### Adaptive EDCA (AEDCA) schemes

While EDCA service differentiation is an important QoS enhancement for DCF, it is not enough to provide strict QoS support for delay-bounded multimedia applications. Moreover, EDCA is known to perform poorly during high channel load because of the excessively high contention rate²⁰,²³. Based on the EDCA framework, several adaptive schemes¹⁷,²³ have been proposed recently. In²³, after each successful transmission, the CWs of different ACs do not reset to $CW_{min}$ as in EDCA.
<figure><img src="image_7.png" /><figcaption>FIG. 6: IEEE 802.11e interframe space (IFS) relationship¹²</figcaption></figure>

<table><caption>TABLE III: Default EDCA parameters</caption><thead><tr><th>ACs</th><th>CW<sub>min</sub></th><th>CW<sub>max</sub></th><th>AIFSN</th><th>TXOPLimit (802.11b)</th><th>TXOPLimit (802.11a/g)</th></tr></thead><tbody><tr><td>BK</td><td>CW<sub>min</sub></td><td>CW<sub>max</sub></td><td>7</td><td>0</td><td>0</td></tr><tr><td>BE</td><td>CW<sub>min</sub></td><td>CW<sub>max</sub></td><td>3</td><td>0</td><td>0</td></tr><tr><td>VI</td><td>(CW<sub>min</sub> + 1)/2 - 1</td><td>CW<sub>min</sub></td><td>2</td><td>6.016ms</td><td>3.008ms</td></tr><tr><td>VO</td><td>(CW<sub>min</sub> + 1)/4 - 1</td><td>(CW<sub>min</sub> + 1)/2 - 1</td><td>2</td><td>3.008ms</td><td>1.504ms</td></tr></tbody></table>

Instead, the CWs are updated according to the estimated channel collision rate which takes into account the varying traffic conditions. Furthermore,¹⁷ proposes the adaptation of backoff timers according to the channel load rate, i.e. a backoff threshold is introduced upon which backoff timers are reduced exponentially fast. AEDCA computes the backoff threshold for each AC based on some analytical observations¹⁷. AEDCA can provide better QoS support for multimedia applications than EDCA in medium and high load cases. It achieves a high degree of fairness among applications of the same priority level.

## 2. PCF-based schemes

### The HCCA scheme

1. (a) In order to provide strict and parameterized QoS support regardless the traffic conditions, the HCF controlled channel access (HCCA) mechanism has been proposed by the 802.11e working group. HCCA uses a poll-and-response mechanism similar to PCF, but
there are many differences between the two mechanisms. For example, HCCA is more flexible than PCF, i.e., QAP can start HCCA during both CFP and CP where PCF is only allowed in CFP. In addition, HCCA solves the three main problems of PCF. (1) A direct link between peer stations is allowed in 802.11e, where stations can communicate each other without going through AP in HCCA. (2) An 802.11e QSTA is not allowed to transmit a packet if the frame transmission cannot be finished before the next beacon, which solves the beacon delay problem with PCF. (3) A *TXOPLimit* is used to bound the transmission time of a polled station. Figure 7 shows an example of an 802.11e beacon interval (the duration between two consecutive beacons), composed of alternated modes of optional CFP and mandatory CP. During CP, QAP is allowed to start several contention-free bursts, called controlled access period (*CAP*), at any time after detecting channel as being idle for a time interval of PIFS. As shown in Figure 6, PIFS is shorter than DIFS and AIFSs, which gives a QAP a higher probability to start HCCA at any instant during a CP than other contending QSTAs. HCCA is more flexible than PCF because the latter must occur periodically after a beacon frame, while a QAP can initiate an HCCA whenever it wishes. Even if PCF is still allowed in 802.11e¹², the flexibility of HCCA makes PCF useless. Thus, PCF is defined as optional in the 802.11e draft. After an optional period of CFP, the mechanisms of EDCA and HCCA which is used in CAP durations, alternate in a beacon interval (see Figure 7). Although HCCA can provide more strict QoS support than EDCA, the latter is still mandatory in 802.11e for supporting QoS specification exchange between QTSAs and QAP. For this purpose, the maximum duration of HCCA in an 802.11e beacon interval is bounded by a variable, *T*<sub>CAPLimit</sub>.

<figure><img src="image_8.png" /><figcaption>FIG. 7: An example of 802.11e beacon interval used in HCF scheduling algorithm</figcaption></figure>

A simple HCF scheduling algorithm is suggested as a reference design in the 802.11e specification¹², providing a parameterized QoS support based on the contract between QAP and corresponding QSTA(s). Before any data transmission, a traffic stream has first to be established and each QSTA is allowed to have no more than eight traffic streams with different priorities. Note that traffic streams and ACs are separated and use different MAC queues. In order to setup a traffic stream connection, a QSTA must send a QoS request frame containing the corresponding traffic
specification (TSPEC) to the QAP². A TSPEC describes the QoS parameter requirement of a traffic stream such as mean data rate, the maximum MAC service data unit (MSDU) size, the delay bound and the maximum Required Service Interval (RSI). The maximum RSI refers to the maximum time duration between the start of successive *TXOPs* that can be tolerated by the application. Intuitively, there is a link between maximum RSI and the delay bound for a given traffic stream. Consequently, the IEEE 802.11e draft suggests that if both the maximum RSI and the delay bound are specified by a QSTA, the HCF simple scheduler only uses the maximum RSI for the calculation of *TXOP* schedule. The simple 802.11e HCF scheduling algorithm is summarized as follows:

On receiving all these QoS requests, the QAP scheduler first determines the minimum value of all the maximum RSIs required by the different traffic streams. Second, it chooses the highest submultiple value of the 802.11e beacon interval duration as the selected service interval (SI), which is less than the minimum of all the maximum RSIs². Third, the 802.11e beacon interval is cut into several SIs and QSTAs are polled accordingly during each selected SI. The selected SI refers to the time between the start of successive *TXOPs* allocated to a QSTA, which is the same for all the stations. As soon as the SI is determined, the QAP scheduler computes the different *TXOP* values allocated to the different traffic streams for different QSTAs, which are *TXOP*₁, *TXOP*₂, etc., shown in the Figure 7. Suppose the mean data rate request of the applications from traffic stream *j* in the QSTA *i* is $\bar{\rho}_{i,j}$ and the nominal MSDU size for this queue is *M*ᵢⱼ, then the number of packets arriving in the traffic stream during the selected SI can be approximately computed as follows:

$$N_{i,j} = \lceil \frac{\bar{\rho}_{i,j} SI}{M_{i,j}} \rceil. \qquad (1)$$

Thus the QAP scheduler computes the allocated *TXOP*, *T*ᵢⱼ for the traffic stream *j* in QSTA *i* as follows:

$$T_{i,j} = \max(\frac{N_{i,j} M_{i,j}}{R} + O, \frac{M_{max}}{R} + O), \qquad (2)$$

where *R* is the PHY layer transmission rate and *M*max is the maximum MSDU size (i.e. 2304 bytes). *O* refers to the transmission overheads due to PHY/MAC layer frame headers, IFSs, ACKs and poll frames. *O* is in time units and is computed as 2*SIFS* + *T*ACK in this chapter.

Fourth, the QAP scheduler sums all the *TXOP* values of different traffic streams in a QSTA *i* as: *TXOP*ᵢ = Σⱼ=1 *T*ᵢⱼ, where *T*ᵢⱼ is the number of active traffic streams in QSTA *i*. Then, the QAP scheduler allocates the time interval of *TXOP*ᵢ to QSTA *i* and allows the QSTA to transmit multiple frames during this time interval. In this way, the QAP scheduler is supposed to allocate the corresponding *TXOP* for transmitting all the arriving frames during the selected SI. Thus, the QAP scheduler is expected to control the delays.

An admission control algorithm is also suggested in the simple HCF scheduler: Using the above scheduling algorithm, the total fraction of transmission time reserved for HCCA of all *K* QSTAs in an 802.11e beacon interval can be computed as: Σⱼ=1 *TXOP*ᵢ/SI. In order to decide whether or not a new request from a new traffic flow can be accepted in HCCA, the QAP scheduler only needs to check if the new request of *TXOP*ᵢ₊₁ plus all the current *TXOP* allocations are lower than or equal to the maximum fraction of time that can be used by HCCA:

$$\frac{TXOP_{K+1}}{SI} + \sum_{i=1}^{K} \frac{TXOP_{i}}{SI} \le \frac{T_{CAPLimit}}{T_{Beacon}}, \qquad (3)$$

where *T*CAPLimit is the maximum duration bound of HCCA and *T*Beacon represents the length of a beacon interval.

In Figure 7, each QSTA is polled once per SI according to the HCF scheduling algorithm. This scheduling algorithm assumes that all types of traffic are CBR, so the queue length increases linearly according to the constant application data rate. However, a lot of real-time applications, such
as videoconferencing, have variable bit rate (VBR) characteristics. The simple HCCA scheduler may cause the average queue length to increase and may possibly drop packets. Even if the mean transmission rate of the application is lower than the rate specified in QoS requirements, peaks of transmission rate may not be absorbed by *TXOPs* allocated according to the QoS requirements. Some adaptive schemes that take into account fluctuation of traffic transmission rates are thus necessary. In the following sections, we describe two different schemes, FHCF and SETT-EDD which enhance the performance of the IEEE 802.11e scheduler.

## The FHCF scheme

FHCF² is composed of two schedulers: a QAP scheduler and a node scheduler. The QAP scheduler estimates the varying queue length of each traffic stream in every QSTA before the next SI. Considering that traffic is VBR and the estimation may be incorrect, the QAP scheduler uses an estimation of errors from the real queue length to adjust the prediction. Then the QAP scheduler compares the adjusted estimated queue length with the ideal queue length before allocating *TXOP* to a QSTA. Here, the ideal queue length refers to the queue size at the beginning of the next SI which is equal to zero at the end of the current *TXOP*. Actually, the HCF reference scheduling algorithm makes this assumption, but this is only valid when the transmission rate of the application is strictly CBR. Based on the difference between estimated and ideal queue lengths, the QAP scheduler of FHCF computes the value of additional time required to fit the variation of the traffic. When it is time for the QAP to poll a QSTA, the QAP scheduler computes the sum of all the required *TXOPs* of different traffic streams in the QSTA based on ideal queue length distribution and the additional time required to compensate the difference between estimated and ideal queue lengths. On the other hand, the node scheduler in each QSTA performs almost the same computation as the QAP scheduler after receiving the *TXOP* allocation from the QAP, since each QSTA knows exactly its own traffic stream queue sizes before the transmission. Then it can redistribute the time allocation among its different traffic streams according to the new computation. Section §5 will show the performance comparisons between FHCF and HCF through the simulations.

## The SETT-EDD scheme

The SETT-EDD scheme⁹ uses the same admission control algorithm rather than the one described in 802.11e¹². It uses the delay bounded earliest due date (Delay-EDD) scheduling algorithm⁶ which polls each queue in every QSTA. Furthermore, the SETT-EDD scheduler aims to consider the impact of bursty errors and link adaptation. Each QSTA selects an independent service interval (SI) and a token bucket of time units (or *TXOP timer*) is used. The *TXOP timer* of each QSTA increases at a constant rate corresponding to the total fraction of time the QSTA can spend in the HCCA *TXOP*. The *TXOP timer* is bounded by the *TXOPLimit* value defined in 802.11e¹². A QSTA can be polled only when the value of *TXOP timer* is greater than or equal to the minimum value of *TXOP*. This ensures the transmission of at least one frame using the minimum PHY data rate. The SETT-EDD improves the performance of the HCF scheduler by reducing the packet loss ratio and delay of video streams. In⁹, it is also demonstrated that the widely-used two-states Markov chain model cannot capture the channel characteristics of 802.11 WLAN with link-adaptation implementations, because the station experiencing a bad channel (with a low signal to noise ratio) can still transmit and receive packets with a lower bit rate. There is a scalability problem in the SETT-EDD scheduler implementation because the QAP needs to calculate the deadline for each traffic stream in every QSTA. When the number of QSTAs increases, this scheduling algorithm becomes inefficient.
## V. SIMULATION ANALYSIS

We analyze several QoS enhancement schemes through ns-2 simulations. Due to limited space, we only provide comparisons between AEDCA and EDCA, and between FHCF and HCF in this section.

### A. AEDCA versus EDCA

We vary the channel load by increasing the number of active QSTAs, see Table IV. Each QSTA transmits three types of flows (audio, video, and data streams) to the same destination, QSTA0. We select 802.11a as PHY layer, the PHY data rate is set to 36 Mbps and other parameters for the three flows are shown in Table V. Every simulation lasts 15 seconds. Most simulation results are averaged over 5 simulations with random flow starting time except that the fairness curves are averaged over 20 simulations.

<table><caption>TABLE IV: Load rate versus number of QSTAs</caption><tr><td>Number of QSTAs</td><td>4</td><td>6</td><td>8</td><td>10</td><td>12</td><td>14</td><td>16</td></tr><tr><td>Load rate (%)</td><td>19</td><td>31</td><td>44</td><td>55</td><td>68</td><td>80</td><td>100</td></tr></table>

Figure 8 shows that AEDCA improves significantly the total goodput of EDCA, mainly in high load situations (around 33% total goodput gain when the channel is fully loaded). This is because AEDCA reduces the number of collisions a lot in both moderate and high load rate cases as shown in Figure 8. Moreover, we observe in Figure 9 that AEDCA provides constant goodput for multimedia flows (both voice and video streams) whatever the channel load while the goodput of video flow degrades in moderate load case with EDCA. Figure 10 shows the latency distribution for different flows with AEDCA and EDCA for a channel load equal to 80%. Recall that on a cumulative latency distribution plot, a perfect result would coincide with the y-axis, representing 100% of packets with zero latency. Although a zero latency for all the packets is impossible in reality, the scheme that provides an almost vertical line close to the y-axis will be the best one. We observe that AEDCA delivers 90% of voice stream packets within 1.5ms, 90% of video packets within 4ms, and 90% of background packets within 1.7s. While delays are much larger with EDCA, it can transmit only about 41% of voice packets within 1.5ms, 5.7% of video packets within 4ms, and 3% of background packets within 1.7s. Improvements of delay performance come from the fact that AEDCA obtains lower collision rate and less idle backoff time than EDCA.

<table><caption>TABLE V: Simulation parameters for the three ACs</caption><thead><tr><th></th><th>Audio</th><th>Video</th><th>Background</th></tr></thead><tbody><tr><td>Transport protocol</td><td>UDP</td><td>UDP</td><td>UDP</td></tr><tr><td>AC</td><td>VO</td><td>VI</td><td>BE</td></tr><tr><td>CW<sub>min</sub></td><td>7</td><td>15</td><td>31</td></tr><tr><td>CW<sub>max</sub></td><td>15</td><td>31</td><td>1023</td></tr><tr><td>AIFSN</td><td>2</td><td>2</td><td>3</td></tr><tr><td>Packet Size</td><td>160 bytes</td><td>1280 bytes</td><td>1500 bytes</td></tr><tr><td>Packet Interval</td><td>20 ms</td><td>10 ms</td><td>12.5 ms</td></tr><tr><td>Flow Sending Rate</td><td>8 Kbytes/s</td><td>128 Kbytes/s</td><td>120 Kbytes/s</td></tr></tbody></table>
<figure><img src="image_9.png" /><figcaption>FIG. 8: AEDCA versus EDCA: total goodput (left) and collision rate (right)</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>FIG. 9: Goodput of different flows: AEDCA (left) versus EDCA (right)</figcaption></figure>
<figure><img src="image_11.png" /><figcaption>FIG. 10: Latency distribution: AEDCA (left) versus EDCA (right)</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>1. (a)</figcaption></figure>

<caption>FIG. 11: Fairness: AEDCA (left) versus EDCA (right)</caption>

While service differentiation and QoS support for multimedia applications is very important, fairness between applications with the same priority is also an important issue in the design of 802.11 MAC protocols. In order to evaluate the fairness performance of AEDCA and EDCA, we choose the well-known Jain's fairness index¹⁵:
$$J = \frac{(\sum_{i=1}^{n} g_i)^2}{n \sum_{i=1}^{n} (g_i)^2}, \qquad (4)$$

where n represents the total number of the flows with the same priority in a BSA, and $g_i$ is the goodput of flow i. We recall that $J \le 1$, and it is equal to 1 if all $g_i$ are equal which corresponds to the highest degree of fairness between different stations. As shown in Figures 11, AEDCA is fairer than EDCA whatever the channel load and the type of traffic. The reason mainly comes from the fact that AEDCA performs the adaptive fast backoff algorithm, which resolves collisions efficiently and provides fair transmission opportunities for all the QSTAs.

## B. FHCF versus HCF

FHCF is implemented in ns-2 simulator and source code is available at³. To evaluate the performance of both the QAP scheduler and the node scheduler, two kinds of simulation topologies are used. The first topology contains 18 mobile QSTAs and 1 fixed QAP with only one traffic stream per station (see Section V B 1), and aims to evaluate the performance of the QAP scheduler. The second topology is composed of 6 QSTAs and 1 QAP (see Section V B 2), which is used to evaluate the performance of the node scheduler. Each station has three traffic streams with different priorities.

### 1. Scenario 1

In Scenario 1, 6 QSTAs send highest priority on/off PCM audio streams (64Kbps), another 6 QSTAs send VBR video streams (200Kbps in average) with medium priority and 6 QSTAs send CBR MPEG4 video streams (3.2Mbps) with low priority. Table VI and Table VII summarize the main simulation parameters. All flows use UDP as transport layer protocol. PCM Audio flows are mapped to the 6th traffic stream of the MAC layer whereas VBR H.261 and CBR MPEG4 video flows are respectively mapped to the 5th and 4th traffic stream. The different VBR flows have been obtained with the VIC¹⁹ videoconferencing tool using the H.261 coding and QCIF format for typical “head and shoulder” video sequences. The mean transmission rate of 6 traces is close to 200Kbps with a mean packet size of 660bytes and a mean interarrival time of 26ms³. A simple analysis of the trace files shows that the transmission rate distribution follows a Gaussian law and its mean value belongs to a window of 80Kbps around the mean value of 200Kbps. The mean packet size varies between 600 and 700bytes. Packet sizes of these flows belong to a large range of values between 20 and 1024 bytes.

Figure 12 shows that with FHCF, the maximum latency of all flows is bounded by the selected SI from all traffic streams (chosen equal to 50ms). Whereas for HCF, some flows may not meet their QoS requirements. For example, the delays of the VBR flows are completely uncontrolled (see Figure 12) because the queue lengths increase dramatically during some time period. Note that the maximum delay of HCF can be controlled if TXOPs are allocated according to the maximum transmission rate of the VBR flows. In this case, fewer flows with HCF than with FHCF can be accepted in HCCA.
<table><caption>TABLE VI: Description of different traffic streams</caption><thead><tr><th>Node</th><th>Application</th><th>Arrival period (ms)</th><th>Packet size (bytes)</th><th>Sending rate (Kbps)</th></tr></thead><tbody><tr><td>1 → 6</td><td>PCM Audio</td><td>4.7</td><td>160</td><td>64</td></tr><tr><td>7 → 12</td><td>VBR video</td><td>≈ 26</td><td>≈ 660</td><td>≈ 200</td></tr><tr><td>13 → 18</td><td>MPEG4 video</td><td>2</td><td>800</td><td>3200</td></tr></tbody></table>

<table><caption>TABLE VII: PHY and MAC layer parameters</caption><tr><td>SIFS</td><td>16μs</td></tr><tr><td>DIFS</td><td>34μs</td></tr><tr><td>ACK size</td><td>14bytes</td></tr><tr><td>PHY rate</td><td>36Mbps</td></tr><tr><td>Minimum Badwidth</td><td>6Mbps</td></tr><tr><td>SlotTime</td><td>9μs</td></tr><tr><td>CCA Time</td><td>4μs</td></tr><tr><td>MAC header</td><td>38bytes</td></tr><tr><td>PLCP header length</td><td>4bits</td></tr><tr><td>Preamble length</td><td>20bits</td></tr></table>

<figure><img src="image_13.png" /><figcaption>FIG. 12: Latency distribution for FHCF and standard HCF</figcaption></figure>

Figure 13 shows the fairness comparison between FHCF and HCF when the HCCA load rate is modified by increasing the transmission rate of the CBR MPEG4 traffic. The Jain's fairness index¹⁵ is also used to compare fairness for different schemes between the same kinds of traffic:

$$J = \frac{(\sum_{i=1}^{n} d_i)^2}{n \sum_{i=1}^{n} d_i^2}$$

where $d_i$ is the mean delay of the flow $i$ and $n$ is the number of flows with the same priority.
<figure><img src="image_14.png" /><figcaption>FIG. 13: Fairness versus load for FHCF and standard HCF</figcaption></figure>

For both VBR and CBR video flows, FHCF is much fairer than HCF since the QAP scheduler of FHCF can estimate the varying queue length and allocate the *TXOP* fairly between different flows.

## 2. Scenario 2

In Scenario 2 (see Table VIII), each QSTA sends on/off PCM audio, VBR video (H.261), and CBR video (MPEG4) flows simultaneously through three traffic streams with different priorities. The HCCA load rate has been changed by increasing the packet size of the CBR MPEG4 flow from 600bytes (2.4Mbps) to 1000bytes (4Mbps) using a 100bytes increment and keeping the same inter-arrival period of 2ms.

Figures 14 and 15 show respectively the mean delays and the fairness of several types of flows obtained with the various schemes for different loads of the network (see Table VIII).
<figure><img src="image_15.png" /><figcaption>FIG. 14: Mean delays versus load</figcaption></figure>

<table><caption>TABLE VIII: Description of different traffic streams</caption><thead><tr><th>Node</th><th>Application</th><th>Arrival period (ms)</th><th>Packet size (bytes)</th><th>Sending rate (Kbps)</th></tr></thead><tbody><tr><td>1 → 6</td><td>Audio</td><td>4.7</td><td>160</td><td>64</td></tr><tr><td>1 → 6</td><td>VBR video</td><td>≈ 26</td><td>≈ 660</td><td>≈ 200</td></tr><tr><td>1 → 6</td><td>CBR video</td><td>2</td><td>600 → 1000</td><td>2400 → 4000</td></tr></tbody></table>

### Audio and VBR H.261 video flows

Figure 14 shows that with FHCF, delay curves are almost horizontal lines which means that delays do not strongly depend on the network load. For the same reason as in Scenario 1, the delays of VBR
<figure><img src="image_16.png" /><figcaption>FIG. 15: Fairness versus load</figcaption></figure>

flows sent using the standard HCF scheme are very high (the mean delays for the VBR flows are almost 300ms).

As shown in Figure 15, Jain's fairness index between audio flows obtained with HCF and FHCF, is very high. The reason is that both of them allocate excessive *TXOPs* to these audio flows. Concerning VBR flows, FHCF is always fairer than HCF.

CBR MPEG4 video flows

Figure 14 shows that the mean delays of both FHCF and HCF are not affected by the traffic load, while the delay of FHCF is smaller than that of HCF. As seen in Figure 15, we observe that FHCF is fair between the different CBR flows on a large range of loads since node schedulers succeed in redistributing time among the different traffic streams up to a very high network load (96%). However, with HCF fairness performance is poor since the schedulers are not able to absorb traffic fluctuations.

VI. CONCLUSION

In this chapter we describe the QoS issues at the IEEE 802.11 MAC layer. We summarize different QoS-enhanced techniques proposed for 802.11 WLAN, including the upcoming IEEE
QoS-enhanced standard, 802.11e. We also provide different criteria to classify different enhanced schemes. The performance evaluations of some QoS-enhancement schemes (including 802.11e) are conducted through computer simulations. The simulation results show that the upcoming 802.11e standard can offer certain QoS support, but it cannot provide good quality for real-time multimedia applications in some cases. Adaptive schemes are shown to perform well and need to be investigated further in future work. Moreover, good 802.11e analytical models and real testbed experiments are required to optimize the performance of 802.11e networks.

Acknowledgments

The authors would like to thank Prof. Torsten Braun (from University of Bern), Mr. Mathieu Lacage and Dr. Wen-Shin Lee (from Galaad project of INRIA) for reading the draft of this chapter and providing helpful comments.

<footnote n="1">¹ I. Aad and C. Castelluccia, *Differentiation mechanisms for IEEE 802.11*, Proc. of IEEE Infocom, Anchorage, Alaska, USA, April 2001, pp. 209-218.</footnote>

<footnote n="2">² P. Ansel, Q. Ni and T. Turletti, *An efficient scheduling scheme for IEEE 802.11e*. Proc. of WiOpt (Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks), Cambridge, UK, March 24-26, 2004.</footnote>

<footnote n="3">³ P. Ansel, Q. Ni and T. Turletti, *FHCF: A fair scheduling scheme for 802.11e WLAN*. INRIA Research Report No 4883, July 2003. Implementation and simulations available from "http://www-sop.inria.fr/planete/qni/fhcf/".</footnote>

<footnote n="4">⁴ J. Deng and R. S. Chang, *A priority scheme for IEEE 802.11 DCF access method*, IEICE Trans. in Com. 1999, pp. 96-102.</footnote>

<footnote n="5">⁵ D. A. Eckhardt and P. Steenkiste, *Effort-Limited Fair (ELF) scheduling for wireless networks*, Proc. of Infocom 2000.</footnote>

<footnote n="6">⁶ D. Ferrari, D. Verma, *A scheme for real-time channel establishment in wide-area networks*, IEEE JSAC, Vol. 8, No. 3, April 1990, pp. 368-379.</footnote>

<footnote n="7">⁷ A. Ganz, A. Phonphoem and Z. Ganz, *Robust superpoll with chaining protocol for IEEE 802.11 wireless LANs in support of multimedia applications*, Wireless Networks 2001, pp. 65-73.</footnote>

<footnote n="8">⁸ S. J. Golestani, *A self-clocked fair queueing scheme for broadband applications*, Proc. of Infocom 1994.</footnote>

<footnote n="9">⁹ A. Grilo, M. Macedo, M. Nunes, *A scheduling algorithm for Qos support in IEEE 802.11E Networks*. IEEE Wireless Communications Magazine, Vol.10, No.3, June 2003, pp. 36-43.</footnote>

<footnote n="10">¹⁰ IEEE 802.11 WG, *International Standard [for] Information Technology - Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific Requirements - Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Reference number ISO/IEC 8802-11:1999(E)*, 1999.</footnote>

<footnote n="11">¹¹ IEEE WG, *802.11a, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High-speed Physical Layer in the 5Ghz Band*, September 1999.</footnote>

<footnote n="12">¹² IEEE 802.11 WG, *Draft Supplement to STANDARD FOR Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications: Medium Access Control (MAC) Enhancements for Quality of Service (QoS)*, IEEE 802.11e/Draft 5.0, July 2003.</footnote>

<footnote n="13">¹³ IEEE 802.11 WG, *IEEE 802.11d, Part 3: MAC bridges, ANSI/IEEE Std. 802.1D*, 1998 edition, 1998.</footnote>

<footnote n="14">¹⁴ ITU-T Recommendation H.261, *Video codec for audiovisual services at $p \times 64$ kb/s*. 1993.</footnote>

<footnote n="15">¹⁵ R. Jain, *The art of computer systems performance analysis*. John Wiley & Sons, 1991.</footnote>

<footnote n="16">¹⁶ A. Lindgren, A. Almquist, and O. Schelen, *Evaluation of quality of service schemes for IEEE 802.11 wireless LANs*, Proc. of the 26th Annual IEEE Conference on Local Computer Networks, Florida, USA, November 15-16, 2001, pp. 348-351.</footnote>
<footnote n="17">17 M. Malli, Q. Ni, T. Turletti, and C. Barakat. *Adaptive fair channel allocation for QoS enhancement in IEEE 802.11 wireless LANs*. IEEE ICC 2004 (International Conference on Communications), Paris, June 20-24, 2004.</footnote>

<footnote n="18">18 S. Mangold, S. Choi, P. May, O. Klein, G. Hiertz, and L. Stibor, *IEEE 802.11e wireless LAN for quality of service*, Proc. of European Wireless, Florence, Italy, February 2002.</footnote>

<footnote n="19">19 S. McCanne, V. Jacobson, *Vic: a flexible framework for packet video*. ACM Multimedia, 1995.</footnote>

<footnote n="20">20 Q. Ni, L. Romdhani and T. Turletti, *A survey of QoS enhancements for IEEE 802.11 wireless LAN*, Journal of Wireless and Mobile Computing, John Wiley, Vol. 4, pp. 1-20, 2004, to appear.</footnote>

<footnote n="21">21 D. D. Perkins, and H. D. Hughes, *A survey on quality-of-service support for mobile ad hoc networks*, Journal of Wireless Communications and Mobile Computing 2002, pp. 503-513.</footnote>

<footnote n="22">22 NS-2 simulator, http://www.isi.edu/nsnam/ns/.</footnote>

<footnote n="23">23 L. Romdhani, Q. Ni and T. Turletti, *Adaptive EDCF: enhanced service differentiation for IEEE 802.11 wireless ad hoc networks*, Wireless Communications and Networking Conference, New Orleans, Louisiana, USA, March 16-20, 2003.</footnote>

<footnote n="24">24 J. L. Sobrinho and A. S. Krishnakumar, *Real-time traffic over the IEEE 802.11 medium access control layer*, Bell Labs Technical Journal 1996, pp. 172-187.</footnote>

<footnote n="25">25 N. H. Vaidya, P. Bahl and S. Gupa, *Distributed fair scheduling in a wireless LAN*, Proc. of the Sixth Annual International Conference on Mobile Computing and Networking, Boston, USA, August 2000, pp. 167-178.</footnote>

<footnote n="26">26 A. Veres, A. T. Campbell, M. Barry and L. H. Sun, *Supporting service differentiation in wireless packet networks using distributed control*, IEEE JSAC, Special Issue on Mobility and Resource Management in Next-Generation Wireless Systems 2001, pp. 2094-2104.</footnote>

<footnote n="27">27 M. A. Visser and M. E. Zarki, *Voice and data transmission over an 802.11 wireless network*, Proc. of PIMRC, Toronto, Canada, September 1995.</footnote>

<footnote n="28">28 J. Y. Yeh and C. Chen, *Support of multimedia services with the IEEE 802.11 MAC protocol*, Proc. of IEEE ICC, May 2002, pp. 600-604.</footnote>

<footnote>This request frame is called an ADDTS QoS Action frame in¹².</footnote>

<footnote>For example, if the beacon interval is 500ms and the three maximum RSI values are 150ms, 275ms and 200ms, the QAP scheduler will choose 125ms as selected SI, which is the highest submultiple of beacon interval (500ms) and is smaller than the minimum value of the three maximum RSIs, i.e. 150ms in this example.</footnote>