FORTH-ICS / TR-375 March Experimental Evaluation of QoS Features in WiFi Multimedia (WMM)

Transcription

1 FORTH-ICS / TR-375 March 26 Experimental Evaluation of QoS Features in WiFi Multimedia (WMM) Vasilios A. Siris 1 and George Stamatakis 1 Abstract We investigate the operation and performance of WMM (WiFi Multimedia) mechanisms for supporting Quality of Service. Our test-bed consists of access points based on the Linux operating system and MadWiFi drivers, commercial access points (Cisco 12 series), and wireless stations running Linux and Windows. This report discusses the setting of the mechanisms, and the performance in terms of throughput and jitter for different access classes, in the case of UDP and Voice-over-IP (VoIP) traffic in both the uplink and the downlink directions. Keywords: QoS, wireless contention, access classes 1 ICS-FORTH, P.O. Box 1385 GR Heraklion, Greece. {vsiris,gstam}@ics.forth.gr

2 Contents 1 WMM Equipment Tested Multiband Atheros Driver for Wireless Fidelity (Madwifi) Cisco Aironet 12 Series Wireless Testbed 6 3 Configuration Madwifi Cisco Performance impact for different Access Categories (AC) Impact of downstream UDP traffic on voice performance Linux based Wireless Router Linux based Wireless Bridge Cisco 12 Access Point Impact of upstream UDP traffic on voice performance Impact of the CWmin parameter on Aggregate Throughput Downstream Upstream Impact of CWmin parameter on Service Differentiation Flows originating at different stations Flows originating at the same station

3 List of Figures 1 Testbed topology with a software based wireless router Testbed topology with a software based wireless bridge Testbed topology with a Cisco Aironet 12 Series Access Point Configuration of QoS policy for the Cisco access point Decreased throughput for all ACs in a flooded network (downstream VoIP flow) Increased jitter for all ACs in a flooded network (downstream VoIP flow) Increased percentage of lost packets for all ACs in a flooded network (downstream VoIP flow) Bitrate of upstream VoIP flow Interarrival Jitter of upstream VoIP flow Packet losses percentage for upstream VoIP flow Bitrate of downstream VoIP flow Interarrival Jitter for the downstream VoIP flow Percentage of packet losses for downstream VoIP flow Throughput of upstream VoIP flow with a background UDP flow (downstream) Packet losses for upstream VoIP flow with a background UDP flow (downstream) Interarrival Jitter for upstream VoIP flow with a background UDP flow (downstream) Downstream VoIP flow bitrate Downstream VoIP flow bitrate Downstream VoIP flow interarrival jitter Downstream VoIP flow packet losses Downstream VoIP flow bitrate with no policy in the FastEthernet interface Downstream VoIP flow interarrival jitter with no policy in the FastEthernet interface Downstream VoIP flow packet losses with no policy in the FastEthernet interface Upstream VoIP flow bitrate with no policy in the FastEthernet interface Upstream VoIP flow interarrival jitter with no policy in the FastEthernet interface Upstream VoIP flow packet losses with no policy in the FastEthernet interface Upstream VoIP flow bitrate Upstream VoIP flow interarrival jitter Upstream VoIP flow packet losses Downstream aggregate throughput remains unaffected by the variation of CWmin Upstream aggregate throughput depends on the value of CWmin

4 32 Linear relationship between fractions T hroughput 2 T hroughput 1 and CWmin 1 CWmin The ratio of throughputs is a constant function of the ratio of CWmins. 32 3

5 List of Tables 1 Cisco Aironet 12 Series characteristics AC parameters for the Madwifi access point AC parameters for the wireless clients (Madwifi) Mapping of DSCP value to AC AC parameters for the Cisco Aironet access point

6 1 WMM Equipment Tested 1.1 Multiband Atheros Driver for Wireless Fidelity (Madwifi) Multiband Atheros Driver for Wireless Fidelity, or in short, Madwifi, is a Linux kernel driver for Atheros-based Wireless LAN devices. A key feature of Madwifi is the master operation mode, whereby the driver provides the functionality of a software based access point. MadWifi is work in progress and currently there is no production release available yet. For all the experiments described in this document we used a modified version of Madwifi snapshot taken in 2/7/ Cisco Aironet 12 Series Testing was also carried out using an Aironet 12 access point, that provides a subset of the Wireless LAN QoS features proposed in the 82.11e draft. Application of QoS policies at the access point occurs in the following order: 1. Packets already classified with a non-zero 82.1 Q/P priority. 2. Traffic from voice clients if QoS Element for Wireless Phones is enabled. 3. Policies manually created at the access point. 4. A default classification for all packets in a VLAN. Wi-Fi Multimedia implementation for the Aironet 12 access point provides the following enhancements over the basic QoS mode: The access point adds each packet s class of service to the packet s header. Each access class has its own sequence number. The sequence number allows high priority packet to interrupt the retries of a lower priority packet without overflowing the duplicate checking buffer on the receiving end. WPA replay detection is done per access class on the receiver. Like sequence numbering, WPA replay detection allows high-priority packets to interrupt lower priority retries without signaling a replay on the receiving station. For access classes that are configured to allow it, transmitters that are qualified to transmit through the normal backoff procedure are allowed to send a set of pending packets during the configured transmit opportunity (a specific number of microseconds). Sending a set of pending packets improves throughput because each packet does not have to wait for a backoff to gain access; instead, the packets can be transmitted immediately one after the other. Finally the access point applies basic QoS policies to packets sent to clients that do not support WMM. Table 1 presents the release numbers of the software running in the access point. 5

7 Product/Model Number Top Assembly Serial Number System Software Filename System Software Version Bootloader Version AIR-AP1231G-E-K9 FHK839JVF c12-k9w7-tar ja 12.3(4)JA 12.2(8)JA 2 Wireless Testbed Table 1: Cisco Aironet 12 Series characteristics. Diagrams of our test network appear in Figures 1, 2 and 3. We used three different forms of access points for our wireless testbed. In the first two scenarios we used a Linux Box, equipped with a D-Link AirPlus XtremeG DWL-G65 wireless card (WMM capable), configured as a wireless router or wireless bridge. The wireless card was driven by the Madwifi driver while bridging and routing capabilities were provided by the Linux kernel. In the last scenario we used a Cisco Aironet 12 series access point. In all scenarios we used two wireless clients, running the Fedora Core 4 Linux. Each wireless client was equipped with a cardbus D-Link AirPlus XtremeG DWL-G65 wireless card that was driven by the MadWifi driver in managed mode (a WMM enabled wireless client). Finally, we used a workstation running the Redhat 9 Linux with an updated kernel version (2.4.27), that was connected with the access point in use through a 1 Mbps wireline link. Performance measurements were taken using the iperf traffic generation and analysis tool (a free tool available from the NLANR). Generation of voice like flows with iperf was based on G.711 codec assuming no voice activity detection. We used a constant bitrate flow at 5 packets/sec or 64 Kbps and the payload of each UDP packet was 16 bytes which corresponds to a 2 msec voice payload. The testing was carried out at ICS/FORTH and all measurements were taken over a strong radio link between the access point and the wireless clients. Figure 1: Testbed topology with a software based wireless router. 6

8 Figure 2: Testbed topology with a software based wireless bridge. Figure 3: Testbed topology with a Cisco Aironet 12 Series Access Point. 3 Configuration This section provides an overview of the configuration process we followed for the Madwifi driver and the Cisco AP. 3.1 Madwifi Enabling of the WMM capabilities of the Madwifi driver involves some minor changes at the drivers source code and issuing the following command (make use of Linux wireless tools): iwpriv ath wme 1 and can be checked by issuing the command: iwpriv ath get wme The MadWifi driver supports four access categories (ACs); the voice (VO), video (VI), best effort (BE) and background (BK) AC as described in the WMM specification. Each AC has a different set of values for the Arbitrary Inter-Frame Space Number (AIFSN), the Contention Window minimum (CWmin), the Contention Window maximum (CWmax) and the Transmission Opportunity duration (TXOP). The set of values 7

9 for each AC depends on the physical layer being used. Supported physical layers include 82.11a/b/g, frequency hopping and the proprietary turbo a/g modes. There are also different sets of values for the access point (AP) and the client stations (BSS). We conducted all the experiments using 82.11b physical layer and 11 Mbps transmission rate. The corresponding parameters for the Madwifi driver appear in Tables 2 and 3. The maximum duration (in μsec) a station is allowed to transmit once it has obtained access to the wireless medium can be derived from the TXOPLimit value according to the following relationship: TXOP = TXOPLimit 2 5 (μsec) As a result 188 equals 616 μsec and 12 equals 3264 μsec. The aggressive mode, that appears in the last line of the Tables 2 and 3 is a feature that improves the performance of the best effort AC in case there is no no high priority traffic in the network. The packets that belong to the best effort AC are serviced better when the aggressive mode is enabled due to the lower values of AIFSN and CWmin. Furthermore, the larger value of TXOP permits bursts of packets to be transmitted. If high priority packets are detected the driver will fall-back to the default parameters for the best effort AC. Packets are assigned to ACs based on the Differentiated Services Code Point field (DSCP) value of the IP header in the frame. In Table 4 we present the DSCP values used by the Madwifi driver, for the classification of packets to ACs. AC AIFSN log 2 (CWmin) log 2 (CWmax) TXOPLimit BE BK VI VO AGGRESSIVE Table 2: AC parameters for the Madwifi access point. AC AIFSN log 2 (CWmin) log 2 (CWmax) TXOPLimit BE BK VI VO AGGRESSIVE (disabled) Table 3: AC parameters for the wireless clients (Madwifi). 8

10 AC best effort background video voice DSCP x x8 x28 x3 Table 4: Mapping of DSCP value to AC. 3.2 Cisco The Cisco access point was configured using the web interface provided. We defined a QoS policy in order to enable traffic classification. The Cisco IOS provides many options for defining QoS policies. QoS policies can be based on the Type Of Service (TOS) or the DSCP field of the IP header, as well as on filters that match the IP source/destination address field, the TCP/UDP port numbers, etc. Furthermore, the QoS policy can be applied on incoming and/or outgoing traffic on both FastEthernet and Radio interfaces as can be seen in Figure 4. 9

11 Figure 4: Configuration of QoS policy for the Cisco access point. 1

12 Our QoS policy adopted the same classification scheme we used with Madwifi. Packets were assigned to ACs according to their DSCP value as described in Table 4. In Table 5 we present the default values for the AIFSN (referred as Fixed Slot Time), log 2 (CWmin), log 2 (CWmax) and TXOP parameters, for each AC. AC Fixed Slot log 2 (CWmin) log 2 (CWmax) Transmit Time (AIFSN) Opportunity (μsec) BE BK VI VO Table 5: AC parameters for the Cisco Aironet access point. 4 Performance impact for different Access Categories (AC) 4.1 Impact of downstream UDP traffic on voice performance A number of experiments was carried out in order to analyze the effect of downstream UDP traffic on flows carrying voice over IP (VoIP) in our WMM enabled testbed. In these experiments we incorporated two VoIP flows, one in the upstream and one in the downstream direction, as well as a constant bit-rate UDP flow at the downstream direction. We varied the rate of the downstream UDP flow from 1 to 2 Mbps with a step of 1 Mbps. For each rate value of the downstream UDP flow we conducted four experiments. In each of these experiments we directed the upstream and downstream VoIP flows through one of the available ACs: background, best effort, video and voice. Both VoIP flows were directed through the same AC while the downstream UDP traffic was directed throughput the best effort AC. The metrics we were interested in were throughput, interarrival jitter and losses. The experiments were conducted using all three testbed configurations presented in Figures 1, 2 and 3. This was done in order to compare the results obtained from a testbed based on a Linux Wireless Router or a Linux Wireless Bridge with those obtained from a testbed based on a commercial access point and assess if all these types of testbed behave in a similar fashion Linux based Wireless Router The outcome of the experiments conducted with the Linux Wireless Router testbed are presented in Figures 5 to 1. Figure 5 presents the bitrate of the downstream VoIP flow versus the downstream UDP flow bitrate. It can be seen that no matter what AC we choose to send the VoIP flow through, when the load exceeds the capacity of the wireless interface the throughput of the VoIP flow deteriorates significantly. Similar observations 11

13 can be made from Figures 6 and 7 that present the interarrival jitter for the packets of the downstream VoIP flow and the percentage of lost packets respectively. The results indicate that the testbed with the Linux based Wireless Router does not provide the expected service differentiation when the VoIP flow is directed through the video and voice ACs. Since these ACs have smaller AIFSN, CWmin and CWmax values one would expect them to guarantee a better performance for the downstream VoIP flow. This behavior of the Linux Wireless Router can be attributed to the network implementation of Linux Kernel which is designed to be independent of a specific protocol. This applies both to network and transport layer protocols (TCP/IP) and to network adapter protocols (Ethernet, 82.11). When a packet 1 is currently not handled by a protocol instance, it is normally stored in a queue. The fact that all packets are stored in a single queue before ever reaching the WMM enabled wireless interface results in increased packet losses due to packet drops and increased jitter due to delays imposed by the buffer BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow 6 Throughput (kbps) Downlink UDP flow rate (Mbps) Figure 5: Decreased throughput for all ACs in a flooded network (downstream VoIP flow). On the other hand, the single upstream VoIP flow exhibits expected performance levels. Figure 8 presents the bitrate of the upstream VoIP flow versus the downstream UDP flow bitrate. When the VoIP flow packets are directed through the best effort, video and voice ACs they achieve almost constant bitrate and suffer a small percentage of losses as depicted by Figure 1 even for large rate values of the downstream UDP flow. These ACs have the proper AIFSN, CWmin, CWmax parameter values to compete the 1 Each packet in Linux Kernel is represented by structure called socket buffer. For efficiency reasons socket buffers are the entities that are actually stored in queues and not packets. 12

14 7 6 BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow 5 Jitter (msec) Downlink UDP rate (Mbps) Figure 6: Increased jitter for all ACs in a flooded network (downstream VoIP flow). best effort downstream UDP flow and occupy the channel with high enough probability so as not to loose packets. However, when the upstream VoIP flow is directed through the background AC the outcome of the experiment is high percentage of packet losses and decreased throughput. This is due to the low priority of the background AC which results in small probability to access the wireless medium and thus increased packet losses mainly due to buffer overflow at the wireless node. The different levels of service provided by the different ACs become evident in Figure 9 that presents the interarrival jitter for the packets of the upstream VoIP flow. Interarrival jitter is smallest for the voice AC and increases as the priority of the AC decreases. 13

15 7 6 Percentage of lost packets (%) BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow Downlink UDP rate (Mbps) Figure 7: Increased percentage of lost packets for all ACs in a flooded network (downstream VoIP flow) Throughput (kbps) BE uplink VoIP flow BK uplink VoIP flow VI uplink VoIP flow VO uplink VoIP flow Downlink UDP flow rate (Mbps) Figure 8: Bitrate of upstream VoIP flow. 14

16 BE uplink VoIP flow BK uplink VoIP flow VI uplink VoIP flow VO uplink VoIP flow Interarrival Jitter (msec) Downlink UDP flow rate (Mbps) Figure 9: Interarrival Jitter of upstream VoIP flow BE uplink VoIP flow BK uplink VoIP flow VI uplink VoIP flow VO uplink VoIP flow Percentage of lost packets (%) Downlink UDP rate (Mbps) Figure 1: Packet losses percentage for upstream VoIP flow. 15

17 4.1.2 Linux based Wireless Bridge The results obtained from the set of experiments conducted with the Linux based Wireless Bridge have a strong resemblance to those presented in the previous section. This is mainly due to the fact that the Linux Kernel still intervenes between the two interfaces (ethernet and wireless) and its buffering mechanism affects the effectiveness of the wireless interface to differentiate traffic. The mean bitrate, interarrival jitter and packet loss percentage for the downstream VoIP as well as their 95% confidence intervals are presented in Figures 11, 12 and 13 respectively, for each AC. It can be seen from these figures that there is no service differentiation between high and low priority ACs, similarly to the case of the Linux based Wireless Router. The corresponding diagrams for the upstream VoIP flow are presented in Figures 14, 16 and 15. In the upstream direction the VoIP flow has almost constant bitrate and does not suffer significant packet losses even in the case of high bitrate downstream UDP traffic. This holds even in the case of the background AC, unlike what we saw in the experiments with the wireless router. Furthermore, when the downstream UDP flow transmission rate is above 8Mbps the throughput achieved by the upstream VoIP flow is considerably degraded in some scenarios. This is due to one or more short periods of increased packet losses that occur during the experiment and can be attributed to interference from wireless networks that exist nearby. The effect of WMM traffic prioritization is evident in Figure 16 that presents the interarrival jitter metric. Jitter is caused mainly due to buffering in the wireless node that transmits the upstream VoIP packets. When we use the voice AC to transmit the VoIP flow not many packets are stored in the buffer due to the high channel access probability. Video and best effort AC present similar levels of jitter although the latter AC has lower channel access probability than the first. 16

18 8 7 6 Mean Throughput (Kbps) Downlink VoIP flow marked as BE 1 Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO Downlink UDP flow rate (Mbps) Figure 11: Bitrate of downstream VoIP flow. 8 7 Downlink VoIP flow marked as BE Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO 6 Mean Jitter (msec) Downlink UDP flow rate (Mbps) Figure 12: Interarrival Jitter for the downstream VoIP flow. 17

19 12 1 Downlink VoIP flow marked as BE Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO Mean Losses Percentage (%) Downlink UDP flow rate (Mbps) Figure 13: Percentage of packet losses for downstream VoIP flow Mean Throughput (Kbps) Uplink VoIP flow marked as BE 1 Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Uplink UDP flow rate (Mbps) Figure 14: Throughput of upstream VoIP flow with a background UDP flow (downstream) 18

20 1 9 8 Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Mean Losses Percentage (%) Uplink UDP flow rate (Mbps) Figure 15: Packet losses for upstream VoIP flow with a background UDP flow (downstream) Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO 12 Mean Jitter (msec) Uplink UDP flow rate (Mbps) Figure 16: Interarrival Jitter for upstream VoIP flow with a background UDP flow (downstream) 19

21 4.1.3 Cisco 12 Access Point In this section we present the experimental results obtained from the testbed with the Cisco access point. After configuring the service policy for the Cisco access point, as presented in Configuration section, we are have two options. The service policy can be applied in both the FastEthernet and Radio interface or only in the latter one (see Figure 17 In order to assess the behavior of the Cisco Access point in both cases we conducted two series of experiments. Figure 17: Downstream VoIP flow bitrate. To begin with, we applied the service differentiation policy on both interfaces. The downstream VoIP flow bitrate, interarrival jitter and percentage of packet losses are presented in Figures 18, 19 and 2 respectively. Unlike the scenarios with the Linux Wireless Router and Bridge the Cisco access point provides service differentiation in the downstream direction. When the downstream VoIP flow is directed through the video and voice ACs it does not suffer any throughput reduction or losses. Furthermore, interarrival jitter is also low even when the throughput of the best effort UDP traffic is above 7 Mbps. The output of these experiment indicates that there is adequate performance isolation between high priority and lower priority ACs. When the downstream VoIP flow is directed through the best effort and background ACs throughput decreases and packet losses increase considerably when the downstream UDP traffic exceeds 6 Mbps. However, the best effort AC appears to have very small jitter while the background AC has a much larger one. This is because packets marked as best effort always see a full buffer and face similar delays due to the high rate UDP flow that uses the same queue to send its packets. On the other hand, the background AC has lower transmission probability than best effort AC. This results in frequent buffer overflows and high variability in buffering and transmission delays. Figures 21, 22 and 23 present the results obtained by the downstream VoIP flow when we do not apply any traffic prioritization policy on the FastEthernet interface. The results are similar those of the previous experiment, except in the case of video AC. The video AC in this scenario suffers from throughput reduction and significant losses when the rate of the downstream UDP traffic is above 9 Mbps. This was an unexpected result since voice AC has higher priority than the best effort AC where the downstream UDP flow belongs. The results concerning the upstream VoIP flow are similar in both experiments therefore we will present the results only for the second scenario (no policy in the FastEthernet interface). Figures 27, 28 and 29 present the bitrate, interarrival jitter and 2

22 BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow 6 Throughput (kbps) Downlink UDP flow rate (Mbps) Figure 18: Downstream VoIP flow bitrate. packet losses for the upstream VoIP flow. The outcome of these experiments is similar to the outcome of the experiments conducted with the Linux based wireless router and bridge testbed. However, they differ from the results presented in [1]. In Figure 17 of [1], the author observes poor upstream service differentiation, when the Cisco Access point is used, while our results indicate that upstream service differentiation works as expected. This can be attributed to the newer Cisco IOS version we used in our experiments or to the fact that the author applies his traffic policy only for outgoing traffic as depicted in Figure 6 of [1]. 21

23 BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow 14 Jitter (msec) Downlink UDP rate (Mbps) Figure 19: Downstream VoIP flow interarrival jitter. 7 6 Percentage of lost packets (%) BE downlink VoIP flow BK downlink VoIP flow VI downlink VoIP flow VO downlink VoIP flow Downlink UDP rate (Mbps) Figure 2: Downstream VoIP flow packet losses. 22

24 7 6 Mean Throughput (Kbps) Downlink VoIP flow marked as BE Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO Downlink UDP flow rate (Mbps) Figure 21: Downstream VoIP flow bitrate with no policy in the FastEthernet interface Downlink VoIP flow marked as BE Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO Mean Jitter (msec) Downlink UDP flow rate (Mbps) Figure 22: Downstream VoIP flow interarrival jitter with no policy in the FastEthernet interface. 23

25 12 1 Downlink VoIP flow marked as BE Downlink VoIP flow marked as BK Downlink VoIP flow marked as VI Downlink VoIP flow marked as VO Mean Losses Percentage (%) Downlink UDP flow rate (Mbps) Figure 23: Downstream VoIP flow packet losses with no policy in the FastEthernet interface Mean Throughput (Kbps) Uplink VoIP flow marked as BE 1 Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Uplink UDP flow rate (Mbps) Figure 24: Upstream VoIP flow bitrate with no policy in the FastEthernet interface. 24

26 6 5 Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Mean Jitter (msec) Uplink UDP flow rate (Mbps) Figure 25: Upstream VoIP flow interarrival jitter with no policy in the FastEthernet interface Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Mean Losses Percentage (%) Uplink UDP flow rate (Mbps) Figure 26: Upstream VoIP flow packet losses with no policy in the FastEthernet interface. 25

27 4.2 Impact of upstream UDP traffic on voice performance Next we wanted to investigate the effectiveness of the WMM service differentiation mechanism in case more than one flows, with different priorities, originate at the same host. We conducted this set of experiments using the Cisco access point and a wireless node that generated an upstream VoIP flow and an upstream UDP flow. We, again, varied the rate of the upstream UDP flow from 1 to 2 Mbps with a step of 1 Mbps. For each rate value of the upstream UDP flow we conducted four experiments. In each of these experiments we directed the upstream VoIP flow through one of the available ACs: background, best effort, video and voice. The upstream UDP traffic was directed through the best effort AC for all experiments. The metrics we were interested in were throughput, interarrival jitter and losses and were calculated as means over a 9 sec interval. Figures 27, 28 and 29 present the mean bitrate, mean interarrival jitter and mean losses, respectively, for the upstream VoIP flow versus the bitrate of the upstream UDP traffic. The results presented in these figures indicate that, as the bitrate of the upstream UDP traffic increases gradually, the voice flow suffers throughput reduction and, jitter and losses increase, no matter if we used the voice, video or background AC. Unlike these ACs the best effort AC does not suffer throughput reduction and losses although it presents increased jitter (compared to the three other ACs) when the upstream UDP traffic has bitrate values between 3 and 8 Mbps. In order to interpret the above results we must note that the bitrate of the upstream UDP flow is constrained by the capacity of the wireless interface. Therefore, although we set the iperf client to generate an upstream UDP flow of bitrate higher than the capacity of the wireless node, e.g., 8 Mbps, the client is constrained by the speed its socket buffer is emptied by the system, which depends on the capacity of the wireless interface. Consequently, the results of the experiments for each AC are similar for values (requested) of the upstream UDP traffic larger than 8 Mbps. This also explains the lack of any packet losses for the best effort AC 2 due to buffer overflows. The operating system simply will not cause any buffer overflows; and since both the VoIP flow and upstream UDP flow generation processes are scheduled periodically by the processor, they will both have the chance to transmit their packets. Furthermore, the packet losses that appear when we use the background, video and voice ACs must be attributed to the implementation of the EDCA mechanism and its interaction with the Linux networking mechanism. Even if we use the same AC (background, video or voice) for transmission of the upstream UDP and VoIP traffic, as it was the case with best effort AC described above, we still see a small percentage of packet errors. The results presented in this section designate the need for proper service differentiation mechanisms operating at the network layer, in addition to MAC layer mechanisms, in order to provide different levels of service between flows originating from the same wireless host. 2 There were no packet losses for the upstream UDP flow as well. 26

28 8 7 6 Mean Throughput (Kbps) Uplink VoIP flow marked as BE 1 Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Uplink UDP flow rate (Mbps) Figure 27: Upstream VoIP flow bitrate Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO 25 Mean Jitter (msec) Uplink UDP flow rate (Mbps) Figure 28: Upstream VoIP flow interarrival jitter. 27

29 14 12 Uplink VoIP flow marked as BE Uplink VoIP flow marked as BK Uplink VoIP flow marked as VI Uplink VoIP flow marked as VO Mean Losses Percentage (%) Uplink UDP flow rate (Mbps) Figure 29: Upstream VoIP flow packet losses. 28

30 5 Impact of the CWmin parameter on Aggregate Throughput In this section we will try to assess the effect of the CWmin parameter on aggregate throughput for both downstream and upstream traffic. In order to attain this information we observed the variation of the aggregate throughput achieved by two UDP traffic flows that used the same AC when we changed the CWmin value. Both UDP flows used a constant bitrate of 8 Mbps and a data payload of 14 bytes. The following set of experiments was conducted using the Cisco access point. 5.1 Downstream In the downstream direction both UDP flows originated at the workstation on the wired network and were destined to a different wireless node each. For this set of experiments we used the best effort AC and varied its CWmin parameter in the interval [1, 123] (log 2 (CWmin) ɛ [1, 1]). Each experiment lasted 9 sec and the results are presented in Figure 3. The results indicate that the aggregate throughput remains unaffected by changes of the CWmin parameter. This is due to the lack of any contention between the two flows. They are both scheduled through the same class and use the same buffers along the way. Increase of the CWmin just leads to minor delays because of a possibly higher backoff interval prior to the transmission of each packet. 1 Node 1 Node 2 Aggregate Throughput Mean Throughput (Mbps) log(cwmin) Figure 3: Downstream aggregate throughput remains unaffected by the variation of CWmin. 29

31 5.2 Upstream In the upstream direction each UDP flow originates at a wireless node and is destined to the workstation at the wired part of the network. Like in the previous set of experiments, we used the best effort AC, 8 Mbps bitrate for each flow and varied the log 2 (CWmin) over the same values. The results of this experiment are presented in Figure 31 and bring out the effect of CWmin parameter on aggregate throughput. In this scenario the two wireless nodes content with each other in order to gain access to the wireless medium. In case the CWmin parameter takes a small value, the probability of a collision increases considerably. The aggregate throughput will not deteriorate because of the CSMA/CA backoff mechanism and the limited number of participating nodes. However, the collisions are still there, causing unfairness due to channel capture effects and high throughput variability as indicated by the large 9% confidence intervals. For larger values of CWmin collisions are infrequent and there is very small probability for more than one collisions in a raw to occur. The delay induced by the larger CWmin value however, results in aggregate throughput reduction. 9 8 Node 1 Node 2 Aggregate Throughput 7 Mean Throughput (Mbps) log 2 (CWmin) Figure 31: Upstream aggregate throughput depends on the value of CWmin. 6 Impact of CWmin parameter on Service Differentiation A number of tests was carried out in order to investigate the effect of the CWmin parameter on service differentiation. In these experiments we incorporated two UDP flows, in the upstream direction, that belonged to different ACs. Furthermore, we changed the CWmin, AIFSN and TXOP parameters of these ACs so as to be equal. Specifically, log 2 (CWman) was set to 1, AIFS was set to 3 and TXOP was for 3

32 both ACs. For all experiments we kept the log 2 (CWmin) of the first AC equal to 5 and increased the log 2 (CWmin) of the second one from 5 to 8. The UDP flows were constant bitrate at 8 Mbps and we used the Cisco access point for the experiments. We distinguish two scenarios for our experiments. In the first one the UDP flows were transmitted by two different wireless stations, while in the second one they were transmitted by a single station. 6.1 Flows originating at different stations The results in case of two flows originating at different stations appear in Figure 32 and indicate a linear relationship between ratio T hroughput 2 T hroughput 1 and CWmin 1 CWmin 2.Theseexperimental results depict the effectiveness of the CWmin parameter in providing service differentiation as far as upstream traffic is concerned. 1.8 Throughput 2 / Throughput CWmin 1 / CWmin 2 Figure 32: Linear relationship between fractions T hroughput 2 T hroughput 1 and CWmin 1 CWmin Flows originating at the same station The results in case both flows originate at the same station appear in Figure 33 and point out a constant relationship between ratio T hroughput 2 T hroughput 1 and CWmin 1 CWmin 2. The outcome of this experiment indicates that CWmin parameter alone is not adequate to differentiate service when both flows originate at the same wireless node. This agrees with the results obtained in Section

33 Throughput 2 /Throughput CWmin 1 /CWmin 2 Figure 33: The ratio of throughputs is a constant function of the ratio of CWmins. References [1] Guillem Hernandez. 2cn ce: Evaluation of qos features in ieee 82.11e. Wireless Networks, BT Exact. 32