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

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

While wireless LAN (WLAN) systems have burst on the scene as a viable option for providing data connectivity, many in the sector are questioning how well WiFi systems will do at streaming media around the home. WLANs follow the best effort model used in the Ethernet world. While fine for data transfers, this approach does not play well in a streaming application, where a lost packet can cause a multimedia data transfer to break down.

To improve the QoS capabilities provided on WLAN links, the IEEE 802.11 committee is crafting the 802.11e specification, which will provide QoS enhancements at the MAC layer that allow WLAN systems to efficiently stream audio and video data. In this two-part series, we'll look at the MAC layer changes provided by the 802.11e specification and compare them against the existing 802.11 MAC layer architecture. In Part 1, we'll look at the existing 802.11 MAC layer and examine the challenges it provides. In Part 2, we'll further the discussion by examining the MAC layer provided by 802.11e while also looking at some of the implementation issues designers will encounter when trying to make 802.11e services come to live.

What's All the QoS About?
In general, the term QoS refers to set of qualitative and quantitative traffic characteristics (e.g. throughput, service interval, packet size, delay, jitter, priority, type, etc.), which describes a traffic flow in support of a specific application. 802.11 WLANs provide best-effort services similar to Ethernet. In wired Ethernet, QoS issues have been neglected since data rate is very high and the physical layer's error rate very low. However wireless systems incur very high per-packet overhead with limited bandwidth, so the same does not apply to 802.11.

For example, about 32% of available data rate is consumed by packet fragmentation, interframe spacing, and MAC-level acknowledgment. If request to send/clear to send (RTS/CTS) is enabled, it can approach 50%. In addition heavy traffic load increases collisions and backoffs, so frame delivery time to the peer station increases exponentially. Frequent retransmissions also cause unpredictable delays in the order of tens to hundreds of milliseconds and transmission of pending frames could be blocked.

The quality of most multimedia services involving voice and video transmission deteriorate dramatically if delay increases above certain level. This is a major stumbling block preventing 802.11 to enter new markets such as the wireless AV distribution around the home.

For the wired network, IETF's Integrated Services (IntServ)³ and Differentiated Services (DiffServ)⁴ architectures have been proposed to support guaranteed QoS and traffic prioritization respectively above the link layer. IntServ provides service guarantees to individual traffic flows. A traffic flow is defined as a distinguishable traffic stream of datagrams f rom a unique sender to a unique receiver that results from a single user activity and requires the same QoS. Signaling protocol, e.g. RSVP, must be used prior to data transmission to reserve resources at every hop (IP router). IntServ provides high levels of precision in resource allocation, however there are some scalability issues since the protocol requires maintaining a soft state for each flow at every router along the reservation path.

In contrast, DiffServ mechanisms do not use per-flow signaling, and as a result do not consume per-flow resources within the routing infrastructure. The DiffServ protocol allocates different service levels to different groups of users, which means that all traffic is distributed into groups or classes with different QoS parameters. This reduces maintenance overhead in comparison to IntServ, as state awareness is required only at edge routers. At the edge router, datagrams are classified as belonging to the certain service class and then conditioned (marked, policed a nd shaped) according to a service level agreement. Once the datagram is in the DiffServ domain it gets the same treatment from all the routers according to the service category with which it has been marked by the edge router.

When used to support applications with quality of service requirements, each 802.11 WLAN may provide a single link within an end-to-end QoS environment that may be established between and managed by higher layer entities. The 802.11 QoS facility requires the 802.11 MAC sublayer to incorporate features that are not traditional for MAC sublayers. In addition, it may be necessary for certain higher layer management entities to be "WLAN aware", at least to the extent of understanding that the available bandwidth may be subject to sudden and unavoidable changes. In order to support both IntServ and DiffServ protocols the 802.11e Task Group has proposed a number of enhancements to the MAC layer.

The Original WiFi MAC
The main purpose of the 802.11 MAC layer is to provide reliable data services to the user of the MAC (i.e. higher layer protocols) and to control fair access to the shared wireless medium. For this paper, we consider an infrastructure basic service set (BSS) composed of an access point (AP) and a number of stations (STAs) associated with the AP.

To provide reliable data services the 802.11 standard defines a frame exchange protocol. The minimum exchange sequence consists of two frames: a frame sent from source to the destination and an acknowledgment (ACK) sent from destination to source if the frame is received successfully. For every frame received at the MAC, the frame check sequence (IEEE 32-bit CRC) is checked. If the source does not receive the expected ACK or the FCS fails, the frame is re-transmitted. This mechanism consumes some of the available bandwidth, but it allows coping with error conditions such as interference in the wireless medium. In general it is more efficient to ensure data integrity at the link layer than leaving it up to higher lay er protocols, which rely on mechanisms such as timeouts measured in seconds instead of milliseconds at the link layer.

In addition to this basic frame exchange sequence, an optional RTS/CTS mechanism is defined to increase the robustness of the protocol and address problems such as the "hidden node". Under this mechanism, an STA sends a RTS frame to the destination before transmitting any MAC service data unit (MSDU). The destination then responds with a CTS frame once it has correctly received a RTS. The source can then send the MSDU after receiving the expected CTS response.

All frames, including RTS and CTS frames, contain duration information about the length of the MSDU/ACK transmission. Based on this information all surrounding STAs can update an internal timer called network allocation vector (NAV) and defer any transmission until this timer expires. Even if a hidden STA cannot hear the RTS from the source STA, it will be able to receive the CTS response from the destination STA and update i ts NAV accordingly. This mechanism protects transmission between STAs against unexpected transmissions from hidden STAs, and it is also used by the 802.11g amendment to protect unexpected transmissions from legacy equipment.

The 802.11 standard specifies two channel access functions: distributed coordination function (DCF) and point coordination function (PCF). Both channel access functions and their limitations in the support of QoS traffic are discussed in the following sections.

DCF—The Basic Access Method
As the basic channel access function of 802.11, DCF allows sharing of the wireless medium between compatible physical layer (PHY) devices through the use of a carrier sense multiple access with collision avoidance (CSMA/CA) protocol. This mechanism is mandatory for all STAs, including 802.11e QSTAs.

Carrier sense is performed using both physical and virtual mechanisms. Physical carrier sense means before attempting any transmission a STA senses the channel condition and tha t the wireless medium is idle for a certain time period. The duration of the time period varies, but the one used before a transmission attempt under normal condition is called the DCF interframe space (DIFS).

To avoid collision between two simultaneously transmitting STAs, a backoff algorithm is used as well as deferral of transmission for DIFS time. When there are pending transmission requests and the wireless medium is detected busy, an STA would wait until the wireless medium is idle for DIFS time. Then it draws a random number from a range of values, and this number is used to calculate an addition time period that it has to wait. The range from which the random number is drawn is called the contention window (CW), which varies depending on the number of previous re-transmission attempts. If the wireless medium is detected to become busy during backoff, the count down is suspended. It is resumed once the wireless medium is detected to be idle subsequently for DIFS time.

Collision avoidance is a chieved by a virtual carrier sense mechanism. Each STA maintains an internal timer, called the network allocation vector (NAV), which indicates when the wireless medium is busy. A duration value is included in each frame that is transmitted by a STA, which indicates how long the transmission lasts, including any subsequent acknowledgements and fragments. All STAs in the vicinity receives the frame and uses the duration value to update its NAV. Then when a STA is about to start a transmission, it first checks that its NAV is zero. If not, it must wait until it counts down to zero because the NAV indicates that another STA has access to the wireless medium.

On winning contention to the wireless medium an STA can transmit one MSDU. Then the STA waits for a time period called short iterframe sace (SIFS) for the ACK from the MSDU recipient. SIFS is shorter in duration than DIFS, which gives the ACK frame highest priority for accessing the wireless medium. This ensures that any other STA would not start trans mission while the ACK is expected. If the ACK is not received after SIFS, retransmission is attempted until either the number of retransmission has exceeded certain thresholds or the lifetime of the MSDU has expired. In these cases, the MSDU is discarded.

MSDUs can also be fragmented to increase the probability of successful transmission. However since each fragment of the MSDU is individually acknowledged, fragmentation significantly increases transmission overhead of the MSDU. An example of DCF frame exchanges is shown in Figure 1 with STA D being a hidden node from STA A.

Figure 1: Example DCF frame exchangesequence.
PCF for Controlled Access
PCF is an optional channel access function in the 802.11 standard that is designed to support time-bounded services. Contention free access to the wireless medium is controlled by a point coordinator (PC) collocated with the AP.
802.11 defines two periods between two consecutive delivery traffic indication message (DTIM) beacon frames: the contention free period (CFP) and contention period (CP). In general, the AP sends periodic beacon frames, although these frames can be delayed by a busy wireless medium, and carry synchronization and network (BSS) information. DTIM beacon frames are used by the PC to indicate the start of a CFP.
During CP all the STAs contend for the wireless medium using DCF. During CFP, the AP schedules transmissions to and/or from individual STA using a polling mechanism. There is no contention between STAs during CFP. CFP starts when the AP obtains access to the wireless medium using PCF interframe space (PIFS) timing at the target beacon transmission time (TBTT). PIFS is shorter than DIFS, but longer than SIFS. Therefore PCF gets higher priority of access than DCF, but does not interrupt any ongoing DCF transmissions. Once PCF obtains access to the wireless medium SIFS timing is used for fram es exchanges during CFP.
Figure 2 illustrates an example PCF frame exchange sequence. Polling is started by the PC sending a CF-Poll frame to one of the pollable STAs. If the PC itself has pending transmission, it could use a data frame piggybacking a CF-Poll frame. The polled STA can respond with a Data+CF-ACK frame, or with a CF-ACK frame only if there is no pending transmission in the STA. Once the frame exchange sequence with one STA is completed, the PC then sends CF-Poll to another STA in its list of pollable STAs. When the PC has finished polling all pollable STAs or the CFP duration has expired, the PC broadcasts a CF-End frame to announce the end of the CFP.

Figure 2: Example PCF frame exchange sequence.
The NAV of all STAs are set to maximum at TBTT to protect the CFP from unwanted transmissions. Then the AP broadcasts the actual CFP duration in the beacon, and t he NAV are updated accordingly. At the end of the CFP, all STAs reset their NAV to zero when either they have received a CF-End frame, or the CFP duration expires. From now on until the next DTIM beacon, all STAs contend for the wireless medium using DCF.
QoS Limitations of the Original 802.11 MAC
DCF does not have any provision to support QoS. All data traffic is treated in a first come first serve, best-effort manner. All STAs in the BSS contend for the wireless medium with the same priority. This causes asymmetric throughput between uplink and downlink, as the AP has the same priority as other STAs but with much higher throughput requirement. There is also no differentiation between data flows to support traffic with QoS requirements. When the number of STAs in a BSS increases, probability of collisions becomes higher and results in frequent retransmissions. Therefore QoS decreases as well as overall throughput in the BSS.
Although PCF was designed to support time-bounded traffic, many inadequacies have been identified. These include unpredictable beacon delays resulting in significantly shortened CFP, and unknown transmission duration of polled STA making it very difficult for the PC to predict and control the polling schedule for the remainder of the CFP.
In addition there is no management interface defined to setup and control PCF operations. Therefore it is impossible to setup a PCF policy according to the requirements of higher layer protocols such as DiffServ or IntServ. Also there is no mechanism for STAs to communicate QoS requirements to the AP, which is essential for optimizing the performance of the polling algorithm in the PC.
In summary, neither DCF nor PCF provide sufficient facility to support traffic with QoS requirements.
On to Part 2
That wraps Part 1 in our two-part series. In Part 2, we'll examine the enhancements the 802.11 committee have made at the MAC layer to support m ultimedia transfers.
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. Carlson, 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.