Understanding the MAC impact of 802.11e: Part 2 (By Simon Chung and Kamila Piechota, Silicon and Software Systems)

Understanding the MAC impact of 802.11e: Part 2
By Simon Chung and Kamila Piechota, Silicon and Software Systems, CommsDesign.com
October 30, 2003 (5:38 a.m. EST)
URL: http://www.eetimes.com/story/OEG20031030S0005

The wireless medium has fundamentally different characteristics from a wired medium. When providing QoS, we should remember that the MAC endeavors to provide QoS service guarantees within this inherently unpredictable medium. Therefore bandwidth and latency cannot be guaranteed like a wired system, especially in unlicensed spectrum. To solve this problem, the IEEE 802.11 committee has formed the Task Group E (802.11e) committee to define enhancements to the original 802.11 MAC earlier.

This is the second installment in our look at the impact of 802.11e specification on the MAC layer of a wireless LAN (WLAN) design. In Part 1, we dived into the existing 802.11 MAC and discussed some of the challenges this architecture provides when designers try to stream video over WLAN links. Now in Part 2, we'll dive into the specific enhancements provided by the 802.11e committee. We'll also compare these against the capabilities provided in the original 802.11 MAC specification.

Channel Access Functions
802.11e defines a superset of features specified in the 1999 edition of IEEE 802.11. These enhancements distinguish QoS enhanced stations (QSTAs) from non-QoS STAs (STAs), and QoS enhanced access point (QAP) from non-QoS access point (AP). These features are collectively termed QoS facility.

There are two main functional blocks defined in 802.11e. These are the channel access functions and traffic specification (TSPEC) management. Let's look at each in more detail starting with the channel access functions.

The 802.11e QoS facility defines a new coordination function called hybrid coordination function (HCF) used only in QoS enhance basic service set (QBSS). HCF has two modes of operation: enhanced distributed channel access (EDCA) is a contention-based channel access function that operates concurrently with HCF controlled channel access (HCCA) based on a polling mechani sm, which is controlled by the hybrid co-ordinator (HC). The HC is co-located with the QAP. Both access functions enhance or extend functionality of the original access methods DCF and PCF. EDCA has been designed for support of prioritized traffic similar to DiffServ, whereas HCCA supports parameterized traffic similar to IntServ.

The basic concept of these channel access functions is the transmission opportunity (TXOP). A TXOP is a bounded time interval in which the QSTA is allowed to transmit a series of frames. A TXOP is defined by the start time and a maximum duration. If a TXOP is obtained using the contention-based channel access, it is called an EDCA-TXOP. If a TXOP is granted through HCCA, it is called a HCCA (polled) TXOP.

The duration of the EDCA-TXOP is controlled by the QAP and is distributed to non-AP QSTAs in the beacon frames along with other EDCA related parameters. The duration of a HCCA (polled) TXOP is passed to the non-AP QSTA directly by the HC as part of a QoS CF-Poll frame, w hich grants the HCCA (polled) TXOP (Figure 3).

Figure 3: Relationship between 802.11e's channel access mechanisms.
EDCA is used only during CP, while HCCA can theoretically operate during both CFP and CP. However the 802.11e standard recommends using HCCA during CP only, and discourages its use during CFP. This is mainly due to the complexity in implementing polling used CF-Poll and QoS CF-Poll at the same time. Multicast and broadcast frames are delivered by the QAP during either CP or CFP under EDCA or PCF respectively.
As discussed in Part 1, the original standard mandated acknowledgements for successfully received frames. In 802.11e MAC-level Acknowledgment (ACK) has become optional. This means that when the "no ACK" policy is used, the MAC would not send an ACK when it has correctly received a frame . This also means that reliability of "no ACK" traffic is reduced, but it improves the overall MAC efficiency for time-sensitive traffic, such as VoIP, where the data has certain very strict lifetime.
The "no ACK" option also introduces more stringent real-time constraints since if an ACK is not expected, then the next frame for transmission has to be ready within SIFS time from the end of the last transmission. Designers should bear this in mind when architecting an 802.11e system.
EDCA for Support of Prioritized Traffic
EDCA enhances the original DCF to provide prioritized QoS, i.e. QoS based on priority of access to the wireless medium, and it supports priority based best-effort service such as DiffServ (Figure 4).

Figure 4: Diagram of the EDCA architecture.
Prioritized QoS is realized through the introduction of four access categories (AC), which provide delivery of frames associated with user priorities as defined in IEEE 802.1D.⁵ Each AC has its own transmit queue and its own set of AC parameters. The differentiation in priority between AC is realized by setting different values for the AC parameters. The most important of which are listed below:

Arbitrary inter-frame space number (AIFSN): The minimum time interval between the wireless medium becoming idle and the start of transmission of a frame.

Contention Window (CW): A random number is drawn from this interval, or window, for the backoff mechanism.

TXOP Limit: The maximum duration for which a QSTA can transmit after obtaining a TXOP.

When data arrives at the MAC-UNITDATA service access point (SAP), the 802.11e MAC first classifies the data with the appropriate AC, and then pushes the newly arrived MSDU into the appropriate AC transmit queue. MSDUs from different ACs contend for EDCA-TXOP internally within the QSTA.
The internal contention al gorithm calculates the backoff, independently for each AC, based on AIFSN, contention window, and a random number. The backoff procedure is similar to that in DCF, and the AC with the smallest backoff wins the internal contention.
The winning AC would then contend externally for the wireless medium. The external contention algorithm has not changed significantly compared to DCF, except that in DCF the deferral and backoff were constant for a particular PHY. 802.11e has changed the deferral and backoff to be variable, and the values are set according to the appropriate AC. One possible implementations of the external contention mechanism is illustrated in the Figure5.

Figure 5: Example implementation of the external contention algorithm.
With proper tuning of AC parameters, traffic performance from different ACs can be optimized and prioritization of traffic can be achieved. This requires a central coordinator (QAP) to maintain a common set of AC parameters to guarantee fairness of access for all QSTA within the QBSS. Also in order to address the asymmetry between uplink (QSTA to QAP) and the much heavier downlink (QAP to QSTA) traffic, a separate set of EDCA parameters is defined for the QAP only, which takes this asymmetry into account.
HCCA Support of Paramterized Traffic
HCCA is a component of HCF and provides support for parameterized QoS. It inherits some of the rules of legacy PCF, and it introduces many extensions (Figure 6). Similar to PCF, HCCA provides polled access to the wireless medium. But unlike PCF, QoS polling can take place during CP and scheduling of packets is based on admitted TSPECs.

Figure 6: Diagram of the HCCA architecture.
The central concept of HCCA is controlled access phase (CAP), which is a bounded time interval and formed by concatenating a series of HCCA (polled) TXOPs. Scheduling of HCCA (polled) TXOP and formation of CAP are performed by the HC. Figure 7 illustrates an example frame exchange sequence during the CAP.

Figure 7: Example CAP timing (2 polled-TXOP, different QSTAs).
The HC gains access to the wireless medium based on timing information stored in three MIB variables: dot11HCCWmin, dot11HCCWmax and dot11HCAIFSN. The default values of these MIB variables give PIFS timing, which is shorter than AIFS or DIFS. This gives the HC the highest priority over all non-AP QSTAs in accessing the wireless medium.
802.11e introduces a number of new QoS data frame subtypes. For HCCA (polled) TXOP, the QoS CF-Poll frame is used to grant the TXOP, and then data transfer commences using QoS data frames. QoS-Null frames can be used to terminate a HCCA (polled) TXOP by a non-AP QSTA if it does not have any data to send, or the data transfer has completed. The many different types of QoS Data frames and their associated usage rules increase the efficiency of the 802.11e MAC, although it also increases the complexity of the HCCA scheduler. Figure 7 above illustrates a restricted version of the usage rules for the different QoS data types, in order to reduce complexity but not efficiency.
According to the 802.11e standard there can be up to eight uplink or sidelink traffic streams and the same number of downlink traffic streams within a non-AP QSTA. Each uplink or sidelink traffic stream has its own transmit queue, which means that any non-AP QSTAs can provide parameterized QoS services for up to eight traffic flows. In a QAP the number of supported flows is not limited by the standard but by available resources such as memory.
Traffic Specifications
The traffic specification (TSPEC) is the traffic stream management device specified by the 802.11e standard, which p rovides the management link between higher layer QoS protocols such as IntServ or DiffServ with the 802.11e channel access functions. TSPEC describes characteristics of traffic streams, such as data rate, packet size, delay, and service interval. TSPEC negotiation between peer MAC layers provides the mechanism for controlling admission, establishment, adjustment and removal of traffic streams.
Traffic stream admission control is especially important since there is limited bandwidth available in the wireless medium. Bandwidth access must be controlled to avoid traffic congestion, which can lead to breaking established QoS and drastic degradation of overall throughput. The 802.11e standard specifies the use of Traffic Specification (TSPEC) for such a purpose for both EDCA and HCCA.
QoS management frames, primitives, and procedures are defined for TSPEC negotiation, which is always initiated by the station management entity (SME) of a QSTA, and accepted or rejected by the HC. Requested TSPEC is communic ated to the MAC via the MAC layer management entity (MLME) SAP. This allows higher layer SW, protocols, and application, such as RSVP, to allocate resources within the MAC layer. The message sequence chart (MSC) in Figure 8 illustrates a typical TSPEC negotiation.

Figure 8: Typical TSPEC negotiation.
The high-Level Software Architecture
802.11e significantly increases the complexity of the original 802.11 MAC architecture. Most of the changes in the MAC architecture are logical consequences of introducing HCF with two new channel access functions: EDCA and HCCA. Upgrading from the original 802.11 MAC to 802.11e requires extensive changes to existing functional blocks as well as adding new ones.
Implementation of 802.11e requires significantly increases in memory, particularly RAM. The amount of additional RAM is a function of the increase in the number of transmi t queues. In the original 802.11 there are two queues: broadcast & multicast, and unicast. In 802.11e, there are at least five: broadcast & multicast, and four AC. If HCCA is also implemented, the number of additional queues for traffic streams varies between 1 to 8 for QSTA, and 1 to any number for QAP limited by available memory. Obviously these queues and the associated buffers could be optimised to reduce the amount of RAM memory required, but the increase is still significant. This also depends on the existing SW architecture of the MAC and the OS.
In 802.11e the real-time constraints have become a lot tighter. This is mainly due to the MAC level acknowledgement becoming optional. This challenge can either be overcome by a faster processor or by dedicated hardware logic (preferred solution, but expensive). The selection of which solution to adopt depends on a number of factors, most of them probably not technical but commercial. The chosen approach will most likely be a compromise between performanc e, cost, and time-to-market.
The 802.11e standard is still in draft form and final approval by IEEE is expected at the beginning of 2004. Thus, designers must keep in mind that the material presented may changes, forcing designers to make additional tweaks to support 802.11e at the chip and system level.
Editor's Note: To view Part 1, click here.
References

IEEE, “Part 11, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, ANSI/IEEE Std 802.11, 1999 Edition, (ISO/IEC 8802-11:1999(E)).

IEEE, “Part 11, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium, Access control (MAC) Enhancements for Quality of Service (QoS)”, ANSI/IEEE Std 802.11e, Draft 5.0, July 2003.

R. Braden, D. Clark, S. Shenker RFC1633 “Integrated Services in the Internet Architecture: an Overview.” June 1994.

Blake, D. Black, M. Car lson, E. Davies, Z. Wang, W. Weiss, RFC2475 “An Architecture for Differentiated Service.” December 1998.

IEEE, “Part 3, Medium Access Control (MAC) Bridges”, ANSI/IEEE Std 802.1D, 1998 Edition, (ISO/IEC 15802-3:1998).

About the Authors
Simon Chung is a senior software engineer at the Wireless Systems Business Unit in Silicon and Software Systems (S3). Simon has eight years of experience in developing real-time embedded software and wireless protocols such as DECT, Bluetooth, GPS and 802.11. Simon received a B.E. (Hons) in Electronic Engineering from University College Dublin in 1995 and is a voting member of the IEEE 802.11 Working Group. He can be reached at simon.chung@s3group.com.
Kamila Piechota is a software design engineer in the Medical System Business Unit at Silicon and Software Systems (S3). When not playing volleyball or windsurfing, she can be found working on a diverse range of embedded software projects for communications infrastructure products at (S3). Kamila graduated from Technical University of Wroclaw in 1998 having completed an MSc in Computer Science. She can be reached at kamila.piechota@s3group.com.