Understanding the MAC impact of 802.

11e: Part 2 Page 1 of 7

Understanding the MAC impact of 802.11e: Part 2

Simon Chung and Kamila Piechota, Silicon and Software Systems
Oct 30, 2003 (2:38 AM)
URL: http://www.commsdesign.com/showArticle.jhtml?articleID=16502136

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
mechanism, 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, which
grants the HCCA (polled) TXOP (Figure 3).

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 2 of 7

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).

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 3 of 7

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.5 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:

z Arbitrary inter-frame space number (AIFSN): The minimum time interval between the
wireless medium becoming idle and the start of transmission of a frame.
z Contention Window (CW): A random number is drawn from this interval, or window, for
the backoff mechanism.
z 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 algorithm 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

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 4 of 7

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.

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 5 of 7

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 provides 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.

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 6 of 7

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 communicated 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 transmit 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 performance,
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

1. 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)).

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004
Understanding the MAC impact of 802.11e: Part 2 Page 7 of 7

2. 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.
3. R. Braden, D. Clark, S. Shenker RFC1633 "Integrated Services in the Internet
Architecture: an Overview." June 1994.
4. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC2475 "An Architecture for
Differentiated Service." December 1998.
5. 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.

Copyright © 2003 CMP Media, LLC | Privacy Statement

http://www.commsdesign.com/printableArticle/?articleID=16502136 2/24/2004