Dec 29, 2020
Block Acknowledgement (BA) procedure and Data Quality Optimization of IEEE 802.11e MAC protocol performance and settings
Optimization of IEEE 802.11e MAC protocol performance is addressed by modifying several parameters left open in the standard, like block size and acknowledgement policies in order to improve the channel efficiency. The use of small block sizes leads to a high overhead caused by the negotiation on the other hand, the use of large block sizes causes long delays, which can affect negatively real-time applications (or delay sensitive applications). An event driven simulator was developed, and results with a single service and several services running simul- taneously were extracted. By using the Block Acknowledgement (BA) procedure, for video and background traffics in a single service situation, the capacity was improved in the case when the number of stations is equal or higher than 16 and 12, respectively. However, for lower values of the number of stations, the use of BA leads to a slightly worst system performance. In a scenario with mixture of ser- vices the most advised block size is 12 (less delay in a highly loaded scenario). The number of supported user (total) increases from 30 to 35.
Introduction
Recent years have seen an immense growth in the popularity of wireless applications that require high throughput. To support such growth, standardization bodies such as the IEEE 802.11 have formed task groups to investigate and standardize features providing increased quality of service (QoS) and higher throughputs. One of these extensions is the acknowledgement (ACK) policy feature included in the ratified IEEE 802.11e amendment for QoS support [3], which is the focus of this work. In particular, we investigate the policy regarding the block size for a video application. The Block Acknowledgement (BA) procedure improves system throughput results by reducing the amount of overhead required by a station to acknowledge a burst of received traffic [1,2]. It acknowledges a block of packets by a single ACK, instead of using several ACKs, one for each packet, saving the Arbitration Inter-frame Spacing (AIFS) period, the backoff counter time, and the acknowledgement time. The num- ber of frames that can be transmitted within a block is called block size. It is limited and is not specified in the standard. In this chapter, to find the most suitable block size we have tried several block sizes and several loaded scenarios with and without mixture of services. This chapter is organised as follows. In Section 20.2, a brief introduction to the IEEE 802.11e standard is presented along with the main direc- tive lines of the BA procedure. Section 20.3, gives the description of the state of the art. Section 20.4 defines the problem and the scenario, including details on traffic parameters. Section 20.5 gives the simulation results obtained for several scenarios with and without the use of the BA procedure, with and without mixtures of traffic. Conclusions are given in Section 20.6, as well as suggestions for further work.
IEEE 802.11e User Priorities and Access Categories
The so-called enhanced distributed channel access (EDCA) provides differentiated, distributed access to the medium for Quality Stations (terminals that support IEEE 802.11e) using four access categories (ACs) voice (VO), video (VI), best effort (BE), and background (BK). This differentiation is achieved by mapping the traffic to four queues that correspond to the four AC. The traffic prioritisation is performed by varying the amount of time a station queue senses the channel to be idle before backoff or transmission, or the length of the contention window to be used for the backoff, or the duration a station queue may transmit after it acquires the channel. Each AC contends to access the medium with a single CSMA instance, [3] [1]. Each queue has an Arbitration Inter-frame Spacing (AIFS) period preceding the next backoff contention window (see Fig. 20.1).
Block Acknowledgement
The BA mechanism (see Fig. 20.2) improves channel efficiency by aggregating several acknowledgements into one frame [4,5]. There are two types of BA mech- anisms: immediate and delayed. Immediate BA is suitable for high-bandwidth, low-latency traffic while the delayed BA is suitable for applications that tolerate moderate latency. The QSTA with data to send using the BA mechanism is referred
to as the originator, and the receiver of that data as the recipient. The BA mech- anism is initialized by an exchange of Add Block Acknowledgment (ADDBA) Request/Response frames. After initialization, blocks of QoS data frames can be transmitted from the originator to the recipient. A block may be started within a polled TXOP or by winning EDCA contention. The number of frames in the block is limited, and the amount of state that is to be kept by the recipient is bounded. The MAC Packet Data Units (MPDUs) within the block of frames are acknowledged by a BA control frame, which is requested by a BlockACKReq control frame. The response to the BlockACKReq will acknowledge all the correctly received frames and request the badly received to be transmitted again.
State of the Art
Analytical frameworks to model BA have been published [6–8] but the results are not based on a realistic approach to the problem nor account for the achievable QoS, because the use of several service classes with different priorities (the base for EDCA) is not considered at all. The existing theoretical approaches [6–8] do not consider the hidden terminal problem, assume that the buffer is always full, nor assume a multi-rate scenario. In [6,7], an analytical framework was presented to model an ad-hoc network under the standard IEEE 802.11e with the BA proce- dure for a completely simplified scenario. The hidden/exposed terminal problem is one fundamental issue in WLANs but most of the existing analytical models either assume it does not exist, or do not consider the EDCA features of IEEE 802.11e (or do not account for the delay or any other QoS metric) [6,7]. Results presented in [6,7] express the block size as a function of the goodput in saturation conditions. Results show that the block size should be as high as possible, which can be mis- leading when we consider QoS. In [8] an analytical approach to model the BA in IEEE 802.11e was proposed without accounting for the hidden terminal problem. The multi-rate feature in the same environment was also not considered. Further, the packet loss due to errors in the channel was not taken in consideration. Finally, the use of EDCA procedures, like several virtual queues, for the several classes of service are also not considered, i.e., this work does not consider the IEEE 802.11e standard at all. From the simulation approaches presented in the literature the one that is most similar to the work proposed here was proposed in [9]. In [9] several combinations for the block size are presented where a scheduler based on the delay and amount of data in the buffer is proposed. The work presented here is an improve- ment of this approach and provides a more extensive study on the block size while considering use-perceived QoS.
System, Scenario and Assumptions
A cellular WiFi system was considered where each cell has a set of N+1 IEEE 802.11e stations communicating through the same wireless channel. While station 0 is the QoS Access Points (QAP), the other N are QoS stations (QSTA). Each station has four buffers whose size depends on the kind of service being dealt in order to guarantee a given value for the goodput (payload of the packet at MAC level). These buffers will be filled with a MAC Service Data Units (MSDU) gener- ated that characterises the service being dealt in the given buffer. If the MSDU is bigger than a fragmentation threshold, it will be fragmented. In order to cope with service quality the packet transmission follows the Enhanced Distributed Channel Access (EDCA) IEEE 802.11e MAC procedure. Due to collisions or interference a packet may not be correctly received. The interference issues are addressed by using a radio propagation model. Each packet exits the buffer only after the recep- tion of an acknowledgement, or if it has suffered more than a given collision threshold. The users are assumed to be static, and are distributed uniformly in a square area of 2,500 square meter. The physical layer specification assumed in this work is the IEEE 802.11a standard 802, 1999, [10], that defines an Orthogonal Fre- quency Division Multiplexing (OFDM) based PHY layer that operates in the 5 GHz frequency bands, being able to achieve bit-rates as high as 54 Mbps. The physical
and MAC parameters are presented in Table 20.1. The use of the Request/Clear-to- send (RTS/CTS) procedure is implemented only if the packet size is larger than a given threshold, RTS threshold in Table 20.1.
In the algorithm proposed in [10] the sender chooses the bit-rate that achieves the highest throughput taking into account the SINR estimate. More details on physi- cal layer implementation used in the simulator can be found in [11]. Three types of traffic sources were chosen, namely high priority voice (VO), medium prior- ity video (VI), and low priority FTP data as background traffic (BK). The traffic sources parameters are presented in Table 20.2 as well as the Access Categories (AC) of each type of traffic.
We implemented the BA procedure with minor modification to the existing fea- tures like TXOP and RTS/CTS as already explained and without disturbing the overall TXOP and RTS/CTS procedure. When a TXOP is gained, the transmission starts and the origin will know if a BA procedure is implemented with this desti- nation. If this is true, it will not wait for an acknowledgement, but just a SIFS and start the next transmission for the same destination or not depending on which is the next packet in the buffer. Figure 20.3 presents this procedure for destination 1 that has the BA procedure implemented and for destination 2 without the BA. At the beginning of a transmission for a user with active BA procedure, if the block size threshold is reached, a block ACK request packet is added to the buffer to the top-1 place in the queue to be transmitted as the next in line packet.
Results
Block Acknowledgement with Standalone Services
The objective of the simulations was to investigate the gain of the BA procedure for a single service and for a mixture of services. In terms of grade of service, the voice application supports delays up to 30 ms, the video application supports delays up to 300 ms, while the delay for background applications can be up to 500 ms [13]. As previously mentioned, the BA mechanism improves the channel efficiency by aggregating several acknowledgments into one frame. To investigate the proposed BA procedure for the stand-alone service a BA procedure with a block size of 16 fragments was adopted. This procedure is simulated only for BK and VI traffic. For VO application it is certain that BA is not a solution because of the large delays that occur when the buffer is filled with 16 packets (i.e., the delay of the first one would be 320 ms, application). Figure 20.4 presents the delay for BK and VI traffic. It starts to increase around 12 stations for BK and at 16 stations for VI and increases more for a higher number of stations. As expected, the delay is lower when the BA procedure is used. The improvement (reduction) for BK traffic is 300 ms on the average after 12 stations, while for VI traffic it is 420 ms on the average after 16 stations. The improvement in the goodput is of 2 and 2.2 Mb/s in average, after 12 stations, for BK traffic and after 16 stations for VI, respectively [12].
Block Acknowledgement with Mixtures of Applications
This part of the work explores which should be the policy regarding the block size with mixtures of applications. For the purpose we have investigated the BA policy for a video service, an application that is delay-sensitive. Additionally, we have investigated the BA block size for background service that is not delay sensitive. Simulations were performed for 100 s and around 40 times for each number of stations, 15, 20, 25, 30, 35, 40, 45 and each block size, 4, 8, 12, 16. The users started the negotiation to initiate BA procedure in the beginning of the simulation
so all the packets of video and background traffic were transmitted within the BA procedure. The use of the BA procedure in a scenario with a mixture of applications running at the same time was further studied. On the one hand, the overhead caused by the negotiation to establish the BA procedure, and to maintain the BA causes bad performance when a small block size is used. On the other hand, the packet losses caused by the voice users with higher priority in the system, influences the overall QoS on the system and mainly on the video service since we considered in this simulations, that if a packet is not correctly received at a given time the following packets sent within this block will have the delay of the badly sent packet after transmitted added to their delay, Fig. 20.5.
The impact of packet retransmissions in the delay therefore increased. Figure 20.6 presents the delay for each access category. For BK traffic the delay starts to increase considerably with more than 20 stations (12 in the standard procedure). This service class will transmit very rarely since the voice and video traffic will always be sched- uled first. For video traffic the delay starts to increase in the 35 stations. In contrast with BK and VI, VO applications present a negligible delay.
The delay impacts the most the video application. Figure 20.7 shows the results for various block sizes for transmitted video application. Regardless on the number of stations, the BA procedure reduces the delay. Certain sensitivity is observed for a block size of 16, which is the size that gives the highest delay for a total of 1 — 25 stations. For a larger number of station the best block size is 16 as smaller block sizes are not that efficient in decreasing the delays.
When 30 stations are being served in the system the results for the delay with BA is near 5 ms for all block sizes, while without BA the values of the delay
goes up to 80 ms. For 35 stations the difference is even higher. A minimum near 5 ms is obtained for block size 12 while for delay without BA the delay is near 2.3 s. Results for 40 and 45 advise the use of block size 16, although the network is already overloaded (and the delay will just keep growing up to infinity). When less then 40 stations are present the confidence intervals are very small for all the buffers. When there are 40 or more stations the confidence intervals increase. One can therefore extrapolate that there are stations that manage to transmit and have a small delay while others transmit from time to time, causing very high delays. The behaviour observed in Fig. 20.7 occurs due to the overhead caused by the blockACK request, and the delays caused by bad receptions affected mostly the block size 16, but providing lower delays for higher loaded scenarios. The solution is neither to use a large block size (as large as 16) nor a small block size (as low as 4). The
former increases the delay causing problems to the application using these packets (for more than 35 stations), while the latter causes some unnecessary overhead by requesting very often block ACK requests (for less than 35 stations). The advised block size shall be 12 since it is the one that provides lower delay in a scenario where the load is still manageable, at least for the case where BA is used.
Figure 8 presents the results of the goodput in the system in the downlink. Without the BA the maximum goodput achieved is near 11 Mbit/s, while with BA is near 14 Mbit/s for block sizes 12 and 16. The decreasing behaviour after 25 stations occurs due to the high number of collision, and as the background traffic has low priority ends up not being transmitted giving its turn to voice and video users. As voice traffic provides higher overhead the resulting goodput is lower.
Figure 9 presents the goodput only for the video service class. Only after 30 stations the achieved throughput is different when using and not using BA. The highest goodput is found for block size 16, and is more than 10% higher relatively to the case of standard ACK. The increasing behaviour of the goodput is verified up to 40 stations.
Conclusions
This work investigated the BA size as a policy to decrease delays and ensure a stable system. The investigation was based on tuning several parameters and investigated the effect for a procedure with and without BA. Several policies were investigated. Future work will test policies that provide access to the medium, that ensure some degree of service, based on the channel SINR, delays, bit error rate, can be tested. Although, for lower values of the number of stations, the use of BA leads to a slightly worst system performance, the BA procedure provides an improvement in highly loaded scenarios. The improvement is of 2 and 2.2 Mb/s in average, for BK traffic and VI traffic, respectively. In a scenario with mixture of services the most advised block size is 12 since it is the one that provides lower delays in a highly loaded scenario while the users are still within the capacity of the AP. The number of sup- ported user increases from 30 to 35. Note that 35 stations is the total number of VO plus VI and BK user.
