IEEE 802.11e-Improved QoS in Wireless Networks

IEEE has formed the 802.11e group to develop improvements to the original 802.11 MAC to enhance support for QoS-sensitive applications such as VoIP, videoconferencing, and streaming video. The original 802.11 MAC included two modes of operation: DCF and PCF.

The 802.11e draft specification introduces two new modes of operation: EDCF and HCF. As with the original 802.11 MAC, the 802.11e enhancements are designed to work with all possible 802.11 physical layers (the original 802.11, the current 802.11, 802.11a, and 802.11g).^[29]

EDCF defines eight traffic classes. Various parameters governing back-off can be individually set per traffic class. Medium access is similar to DCF with the addition of arbitration interframe space (AIFS). The station cannot begin decrementing the back-off timer until after AIFS. Within a node, each traffic class has a dedicated queue. Traffic class queues contend for access to the virtual channel. Frames that gain access to the virtual channel then contend for medium.

HCF is analogous to PCF, but it allows a hybrid coordinator (HC) to maintain state for nodes and allocate contention-free transmit opportunities intelligently. The HC uses the offered load per traffic class at each station for scheduling.

802.11e MAC Enhancements

Many priority schemes to support QoS are currently being discussed. IEEE 802.11 Task Group E currently defines enhancements to the previously discussed 802.11 MAC that are called 802.11e. These enhancements introduce two new MAC modes-EDCF and HCF. Both these QoS-enhanced MAC protocols support up to eight priority levels of traffic that map directly to the RSVP protocol and other protocol priority levels.

Enhanced Distributed Coordination Function (EDCF) The major enhancement provided by EDCF versus DCF is the introduction of eight distinct traffic classes. Aside from this, EDCF, as the name suggests, works in a fashion similar to the DCF MAC, except that some of the elements of the MAC are parameterized on a per-class basis. Figure 5-10 illustrates the functioning of EDCF.

Figure 5-10: EDCF and HCF in 802.11 networks

Here, each traffic class starts a back-off after detecting that the channel is idle for an AIFS. The AIFS is at least as large as the DIFS and can be chosen individually for each traffic class. This is the first per-class MAC parameter added in EDCF.

Second, the minimum value of the CW for each traffic class, denoted by CWMin can be selected on a per-traffic-class basis. In DCF, a global constant CWMin is used to initialize all CW values.

Third, when a collision is detected and the CW has to be increased, the value of CW is increased by a persistence factor, which is also determined on a per-traffic-class basis. A value of 1 for the persistence factor gives a CW that stays constant even in the case of collisions, whereas a value of 2 (which is the default) gives a binary exponential back-off identical to DCF. To calculate the CW in case of a collision, use Equation 5-4:

(5-4) 

The CWMax value sets the maximum possible value for the CW on a per-traffic-class basis; however, CWMax is typically intended to remain the same for all traffic classes (at the default valued used in DCF).

Within a station, the eight traffic classes have independent transmission queues. These behave as virtual stations with the previously mentioned parameters determining their ability to transmit. If the back-off counter of two or more parallel traffic classes in a single station reaches zero at the same time, a scheduler inside the station treats the event as a virtual collision. The transmit opportunity (TXOP) is given to the traffic class with the highest priority of the colliding traffic classes, and the others back off as if a collision on the medium occurred.

The QoS parameters, which are provided on a per-traffic-class basis, can be adapted over time. The base station does this by announcing them periodically via the beacon frames, which are transmitted at the beginning of every superframe.

Hybrid Coordination Function (HCF) HCF is an extension of the polling idea in PCF. Just like in PCF, under HCF, the superframe is divided into the CFP that starts with every beacon and the CP. During the CP, access is governed by EDCF, though the HC (generally co-located at the AP) can initiate HCF access at any time (due to its higher priority, it can begin transmitting before the expiration of the DIFS).

During the CFP, the HC issues a QoS CF-Poll to a particular station to give it a TXOP. The HC specifies the starting time and maximum duration as part of the CF-Poll frame. During the CFP, no stations attempt to gain access to the medium, so when a CF-Poll is received, they assume a TXOP and transmit any data they have. The CFP ends after the time announced by the beacon frame or by a CF-End frame.

If a station is given a CF-Poll, it is expected to start responding with data within an SIFS period. If it does not, the HC can take over the medium after a PIFS time and allocate another CF-Poll to another station. This allows very efficient use of the medium during the CFP.

To determine which station to give the TXOP to, the HC uses perstation/per-traffic-class queue length data that it collects and maintains to reflect the current snapshot of the infrastructure BSS. The QoS Control field that has been added to the MAC frame definition enables stations implementing 802.11e to send queue lengths per traffic class to the HC.

Scheduling The MAC defines protocols and mechanisms to perform HCF and EDCF. However, a couple of opportunities exist to perform scheduling decisions that are not determined by pure random number selection as in DCF.

HC Scheduling The HC has a snapshot view of the per-traffic-class/per-station queue length information over time, including that of the AP itself. With this, it has to decide to whom to allocate TXOPs during the CFP. This involves considering at least the following:

• The priority of the traffic class

• The required QoS for the traffic class (low jitter, high bandwidth, low latency, and so on)

• Queue lengths per traffic class

• Queue lengths per station

• The duration of TXOP available and to be allocated

• Past QoS seen by the traffic class

The practice is to implement a simple scheme of calculating a weighted average queue length per station (weights are based on traffic class queues within a station) and allocate the maximum available TXOP within the CFP to the station with the largest average. However, various possible schemes are available to meet different goals.

Endpoint Scheduling Within TXOP When a wireless station gets a TXOP by polling from the HC, the HC does not specify a particular traffic class for the TXOP. This leaves the decision of which traffic class to service in the TXOP up to the wireless station. This decision can depend on the same factors as for the HC scheduler, except the multistation cell-wise aggregation that the HC scheduler uses is not applicable.

By decentralizing this decision, the protocol provides a scalable mechanism of maintaining traffic class history and servicing as per the QoS seen in the past without collecting this information and detail at the AP, making it unwieldy. A simple scheme that always sends data for the highest-priority traffic class pending during the TXOP has currently been implemented.

EDCF and HCF: QoS in 802.11 Networks

EDCF provides significant improvements for high-priority QoS traffic; however, these improvements are typically provided at the cost of worse performance for lower-priority traffic. It also appears that the EDCF parameters can require significant tuning to achieve performance goals. Despite these problems, EDCF is attractive compared to HCF because of its simplicity.

HCF, just like its predecessor PCF, provides for much more efficient use of the medium when the medium is heavily loaded. Unlike PCF, HCF does a good job of channel utilization even when the channel is operating well below capacity. Due to reduced overhead, HCF can provide better QoS support for high-priority streams while allocating reasonable bandwidth to lower-priority streams.

Both coordination functions are backward compatible with DCF and PCF. This fact, along with our results, leads us to believe that EDCF and HCF will soon see ubiquitous adaptation into mainstream WLAN technology.^[30]

^[29]James and Ruth LaRocca, 802.11 Demystified, (New York: McGraw-Hill, 2002), 141-142.

^[30]Priyank Garg, Rushabh Doshi, Majid Malek, Russell Greene, and Maggie Cheng, "Achieving Higher Throughput and QoS in 802.11 Wireless LANs," a white paper from Stanford University, http://milliways.stanford.edu/~radoshi/cs444n/.