Experimental Investigation of IEEE 802.11 e EDCA

Experimental Investigation of IEEE 802.11e EDCA Saty Mukherjee1, Xiao-Hong Peng 2 Electronic Engineering, Aston University Birmingham, UK 1 2

mukherjs@aston.ac.uk x-h.peng@aston.ac.uk

Abstract— We investigate the performance of IEEE802.11e Enhanced Distributed Channel Access (EDCA) using real world hardware in a realistic indoor working environment. TCP streams of different priorities representing traffic types, such as FTP are tested over a wireless network test-bed. Quality of Service (QoS) metrics such as throughput and delay are calculated directly from a passive capture of the channel. We show that EDCA is capable of providing service differentiation. However the QoS guarantee for high priority stations is achieved at the expense of service provided to stations with lower priority.

I. INTRODUCTION With the rapid growth of IEEE 802.11a/b/g networks in airports, coffee shops, homes, offices, the need for Quality of Service (QoS) support is increasing. Applications involving the heavy use of multimedia content, such as video conferencing, VoIP and video on demand start to be used across WLAN’s. Therefore guarantees for bandwidth, error rate and delay are needed in order to provide a usable service. To support QoS, Enhanced Distributed Channel Access (EDCA) is introduced within 802.11e WLAN standards, which builds on the legacy Distributed Coordination Function (DCF), to provide prioritisation for four access categories (AC’s). This is achieved by varying the contention window (CW) size in the back-off mechanism on a per category basis. There has been some pioneering work on EDCA modification in [1, 2] in which results have been verified using a real hardware test-bed. Similarly in [3] the EDCA mechanism is implemented in a field programmable gate array (FPGA). In [4] the authors modify the TxOP (defined in Section II) bursting parameter to enhance multimedia transmission focussing on video transmission. VoIP capacity of a network is evaluated in [5] while modifying buffering requirements and the TxOP value. Both [4, 5] feature hardware test-beds for the experimental work. The focus of this recent work is still on the modification and optimisation of EDCA for a specific traffic type. In our work, however, we aim to show the service differentiation capabilities of EDCA in practical hardware test-bed and its simultaneous effect on low priority and background traffic. II. EXPERIMENTAL TEST-BED SETUP When designing our IEEE 802.11 test-bed we wanted the setup to be simple, yet as realistic as possible to reflect a typical wireless environment. All the tests were conducted in our research lab which is configured as a typical office environment. The room layout is open plan with the access

point at a typical desk height of 1m above ground. In all tests, clients had near line of sight to the access point. There were no significant obstacles in the radio path. The noise power in the area was within the bounds for an office environment, between -85dBm and -95dBm. An overview of the system setup is shown in Fig. 1. A. Hardware environment An infrastructure wireless LAN was established within the research lab. The data transmission rate was fixed at 54Mbps (64-QAM) using the 802.11g PHY, disabling the auto fallback mechanism. 54Mbps OFDM 802.11g channel

Linux Access Point AirPcap® Passive Sniffer

EDCA Laptop Clients

End to End TCP/UDP Connection

Fig. 1 - System setup overview

We used a mid specification desktop PC equipped with a Proxim wireless card described below. The MadWifi 0.94 drivers were used in Master mode to create a soft access point. The laptop clients were fitted with Proxim ORiNOCO 11a/b/g PC Cards, based on the Atheros AR5001X+ chipset. RTS/CTS and specific enhancement features such as Turbo G and extended range were disabled. EDCA parameters on the soft access point were left at default as prescribed in the 802.11 standards. B. Software configuration and integration The soft access point and clients were both running Debian Linux (2.6 kernel) using the MadWifi 0.94 drivers. We used the iPerf utility to generate TCP traffic (Reno version). A receiver window of 64k was used with 1460 byte dummy payloads. Traffic streams were categorised into their respected traffic classes by setting the Type of Service (ToS) field in iPerf. The TCP flows were unrestricted and would use as much bandwidth as the network could offer. The AirPcap device was used in conjunction with the Wireshark protocol analyser to capture all of the raw packets from the ether during testing. To avoid any interaction with the testing procedure, the device was used on a separate PC.

AC_BK AC_BE AC_VO Total

25

Throughput (Mbps)

20

AIFS and contention window sizes dictated in the standard. The service differentiation function of EDCA is clearly visible, to support multiple services with varying levels of QoS. 70 (M(τi) / N) x 100 Delay Distribution

III. RESULTS AND ANALYSIS We introduce a way of deriving the throughput directly from a raw 802.11 frame stream capture. Using Wireshark, we isolate the required stream by filtering traffic between the two required MAC addresses. From this filtered data, we observe

15 10

AC_BK Delay Bound (ms) AC_BE Delay Bound (ms) AC_VO Delay Bound (ms)

60 50 40 30 20 10

5 0 1

0 0

20

40

60

80

100

Time (sec)

the 802.11 frame sequence numbers and using a customised script to determine (a) Total number of frames sent, N; (2) Frame retransmission distribution, R(i); and (c) Frame arrival delay, τ . The time duration of the data capture, T, was derived from the timestamps in the capture file. Let R(i) (i = 1,2,…..n) be the number of frames being retransmitted i times before they are accepted at the receiver, where n is the retry limit for the device. If a frame was retransmitted we assume that it was lost due to noise, collision or failure to pass the frame check sequence (FCS) at the receiver. From this, we can calculate the total number of frame losses Nl as n

N l = ∑ iR (i )

(1)

i =1

The loss rate λ in percent is given by

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20

(2)

Let Nr denote the total number of frames passed to the higher layer at the receiver. Given the TCP data payload size LTCP , the average TCP throughput η during T can then be calculated using

)

N − ∑i =1 iR(i) LTCP N L ( N − N l ) LTCP = η = r TCP = T T T n

By using the microsecond timestamps on each frame in Wireshark we are able to produce a delay distribution, as shown in Fig. 3. We again see the effect of prioritisation on the MAC layer delay. The highest priority AC_VO spends the least time contending for the medium; hence almost 70% of the total frames have a MAC delay of less than 1ms. Comparing this to the lowest priority AC_BK which contends for the medium longer, we notice a much wider spread of delay. About 35% of AC_BK frames fall into the 2ms to 4ms range. More significantly, the jitter is far greater in lower priority streams which can have a considerable effect on time sensitive applications such as VoIP. From the delay distribution we can calculate the expected MAC delay per access category, using n  M (τ i )  E (τ ) = ∑  τi  N i  

(4)

Here M (τ i ) is the total number of frames sent within delay

Nl ×100 N

(

3

Fig. 3 - EDCA MAC Delay Distribution

Fig. 2 - TCP throughput in different access categories

λ =

2

τ (i) Delay

120

(3)

This calculation was based on the assumption that the last retransmission was successful. We compared the captured value of Nr with the calculated result (N - Nl) using (3) and (1), and found that they were identical. This technique can be applied on a per stream or per station basis by simply changing the filter requirements in Wireshark. Fig. 2 shows the effect of service differentiation on three concurrent TCP streams, each set with a different access category. As we can see from Fig. 2, the voice category (AC_VO) has the highest throughput, followed by Best Effort (AC_BE) and then Background (AC_BK). This is due to

bound τ i , while N is the total number of frames sent. Using (4) and the delay distribution we can calculate the expected frame delay per access category, such as AC_BK = 9.03ms, AC_BE = 2.65ms and AC_VO = 1.84ms. The expected frame delay is critical in evaluating the performance of time sensitive applications such as VoIP and interactive video. High delay at the MAC layer can result in much larger latency at the application layer, causing significant problems for any interactive applications. In Fig. 4, with a background TCP stream (AC_BK) already in operation, we introduce a higher priority (AC_BE) TCP stream at t = 30 second. The previous background stream is now throttled back substantially as it contends for the medium with the AC_BE priority stream. TCP bandwidth is reduced from 14 Mbps to approximately 1 Mbps. At t = 60 second, we start the highest priority AC_VO stream. Again we see the effect of prioritisation, as the AC_BE stream is throttled back. As a result of this, the overall throughput is increased in the presence of the AC_VO stream. We believe this is due to the smaller AIFS value and contention window size that allow for greater medium utilisation. The background category, AC_BK suffers greatly in terms of both throughput and MAC delay.

AC_BE is less affected, but still suffers a considerable drop in throughput. AC_BK AC_BE AC_VO Total

20 15

70

10 5 0 0

20

40

60

80

100

120

140

Time (s)

Fig. 4 - Individual EDCA TCP Throughput

(M(τi) / N) x100 Delay Distribution

Throughput (Mbps)

25

DCF in the presence of other higher priority streams. For example, the lowest priority stream in the AC_BK category suffers from 80% lower throughput and 300% higher delay when compared to DCF. A possible solution to this would be to modify the EDCA parameters for introducing more fairness among the four access categories. STA 1 Delay Bound (ms) STA 2 Delay Bound (ms) STA 3 Delay Bound (ms)

60 50 40 30 20 10 0

While the AC_BK category is intended for low priority non-time sensitive traffic and AC_BE for best effort, a throughput reduction of such a magnitude could significantly affect data intensive applications such as peer to peer (P2P) and streaming TCP video such as YouTube and BBC iPlayer. In the latter case of streaming TCP video, which has become very popular in recent years, end users would experience longer initial buffering delays and possible breaks in playback due to the limited bandwidth available. Our recommendation is that only low volume traffic such as VoIP be placed in the AC_VO category, to limit the effect on the streams with lower priorities. In the case of multiple high priority streams, we expect the throttling effect to be even greater. This is an area that we plan to investigate further. STA_1 STA_2 STA_3 Total

25

Throughput (Mbps)

20 15 10 5 0 0

20

40

60 80 Time (s)

100

120

140

Fig. 5 - Individual DCF TCP Throughput

Fig. 5 demonstrates the effect of introducing 3 TCP streams using legacy DCF at t = 30 and t = 60 seconds, respectively. We can clearly see that the lack of service differentiation results in the individual stations sharing the available bandwidth equally. The overall bandwidth remains relatively constant at just over 15 Mbps. All 3 stations have similar retransmission characteristics, resulting in similar throughput and delay figures. Again using (3) and the delay distribution in Fig. 6 calculated for the stations in the DCF test, we can derive the expected frame delay for three stations: STA1 = 3.00ms, STA 2 = 2.48ms and STA3 = 2.65ms. Comparing the performance of EDCA with DCF, we see that AC_BE, the best effort category, has similar characteristics to the results in DCF in terms of MAC delay and throughput. The AC_BK category suffers from considerably worse performance than

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 τ(i) Delay

Fig. 6 - DCF MAC Delay Distribution

IV. CONCLUSIONS Our test-bed results show that high priority traffic using EDCA can reduce MAC delay by 30% and maintain a throughput of over 10 Mbps, in the presence of two lower priority streams. The negative aspect of this is that the lowest priority stream in the AC_BK category suffers considerably in both throughput and delay, compared to the results in DCF under a similar mixed traffic scenario. We have discussed the effects of high priority traffic on data intensive applications such as P2P and TCP video streaming. Our recommendation is to reserve the use of the highest priority AC_VO category for low volume and time sensitive traffic. Future work will focus on the modifications of EDCA parameters such as AIFS, contention window sizes and TxOP, in order to ensure the fairness between different categories, while maximising the utilisation of network resources. This is important for providing QoS for multiple data streams with different applications. V.

REFERENCES

[1] I. Dangerfield, D. Malone, and D. J. Leith, "Experimental Evaluation of 802.11e EDCA for Enhanced Voice over WLAN Performance," presented at Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, 2006 4th International Symposium on, 2006. [2] P. Clifford, K. Duffy, J. Foy, D. J. Leith, and D. Malone, "Modeling 802.11e for data traffic parameter design," presented at Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, 2006 4th International Symposium on, 2006. [3] Y.-S. Yoo, J.-R. Kim, Y.-J. Kim, and J.-D. A. H. J.-D. Huh, "Analysis of EDCA MAC throughput for the IEEE 802.11e WLANs" presented at Convergence Information Technology, 2007. International Conference on, 2007. [4] N. Cranley, T. Debnath, and M. Davis, "An Experimental Investigation of Parallel Multimedia Streams Over IEEE 802.11e WLAN Networks Using TXOP," presented at Communications, 2007. ICC '07. IEEE International Conference on, 2007. [5] I. Dangerfield, D. Malone, and D. J. Leith, "Understanding 802.11e Voice Behaviour via Testbed Measurements and Modeling," presented at Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks and Workshops, 2007. WiOpt 2007. 5th International Symposium on, 2007.