VoIP over 82.11 wireless networks: a packet scheduling approach to provide QoS using Linux Terrence van Valkenhoef and Mishar Mahboob December 13, 25 Abstract In this work, we propose a layer three scheduler to support VoIP (Voice Over IP) over 82.11b WLAN s. We identified the possible bottlenecks situations when a VoIP flow will suffer from increasing jitter, delay and packet loss, such that the degradation on the communications will make the audio unrecognizable in the receiving end. From this standpoint, we conducted various experimental setups, by varying the number of inbound and outbound contending traffic flows, altering the IP layer packet scheduling discipline and collecting statistics of the VoIP flow. The intention of these tests was to stress the different queuing disciplines and compare the results. Our generated statistics imply that a priority based scheduling performs the best compare with other fair scheduling disciplines in terms of delay, jitter and packet loss. Keywords: IEEE 82.11, Delay, Jitter, QoS, VoIP. 1
1 Introduction The IEEE 82.11 standard [1] specifies two channel access mechanisms, namely PCF (Point Coordination Function) and DCF (Distributed Coordination Function). The PCF mechanism is a polling scheme where there is a coordinator AP (Access Point) wish decides which station will transmit. The DCF is a contention channel access mechanism based on CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance). These mechanisms achieve acceptable levels of performance for best effort data transmissions. However, in recent years there has been a growing interest on using 82.11 WLAN as the transport system for carrying telephone traffic from mobile users as well. For this new application PCF and DCF lack of mechanism to support the QoS requirements of VoIP (Voice over IP) traffic. The requirements of VoIP such as end-to-end delay and low delay jitter makes DCF an infeasible option. Also, it has been suggested in [3] that while the PCF mechanism may be used to support QoS it is not scalable, requires to work in conjunction with service differentiation under heavy load and may make the co-existence of DCF and PCF impossible. To solve the problem of supporting of QoS, the 82.11e developed a QoS upgrade to support multimedia applications over in wireless 82.11 networks [2]. Basically, the 82.11e will prioritize traffic on the network, making voice packets to win on contention over data packets. Our work try to solve the problem of supporting VoIP over 82.11b networks by differentiating VoIP packets and schedule their transmission with higher priority than those packets carrying data. The priority schedule will always serve the dedicated VoIP queue while there is at least one packet on it. Our results show that this packet scheduling mechanism perform the best compare to other fair scheduling disciplines. Also, it is evident that no other priority scheduling mechanism will perform better in terms of VoIP packet queuing delay. 2 Related Work Our project is a modified implementation from Kopsel and Wolisz [4]. They differentiated between real time and non real time packets. By using a simple priority queue scheduling technique, QoS can be enforced in the uplink and downlink channel. All traffics are separated into two different queues (real time and non real time).. For voice packets, if the packets queuing delay is more than 25 msec then they discarded them. The work on [3] evaluate the capability of the enhanced point coordination function (EPCF) and enhanced distributed coordination function (EDCF), which are part of the medium access control (MAC) enhancements 2
for QoS in the IEEE 82.11e [2]. In this work the performance of VoIP under EPCF and EDCF is shown through simulations, and the impact of background trafc on the VoIP performance is also evaluated. 3 Problem Formulation Typically, when a station wish to transmit the packets generated by the applications those packets go to single FIFO (First In First Out) queue. Intuitively, if the load generated by the applications is high, the packets of VoIP will have to wait for a larger number of packets generated by other applications to be served. Hence, the end-to-end delay and the jitter will increase. In the Access Point the situation is similar and worse since the transmitted packets from multiple stations to the access point will be enqueued in a single FIFO and attended in the order they arrived. Consider a VoIP constant UDP flow in the order of tens of Kbps. We are interested on evaluating a packet scheduling discipline that classifies the VoIP flows based on the TOS (Type Of Service) bits and will always serve this dedicated queue while there is at least one packet on it. All the other flows will be assign to a second queue. The intuition in this scheme is that VoIP flows are in the order of few tens of Kbps and hence the other flows with less priority will not starve while the queuing delay of the VoIP packets will be minimized. In this work we compared this queuing dicipline with SFQ (Stochastic Fair Queuing) and FIFO (First-In First-Out). 3
4 Experimental Setup For our project we searched for various tools to generate traffic, like IPERF, RUDE/CRUDE such that we could characterize the performance of the scheduling logic. We used DITG (Distributed Internet Traffic Generator) for generating background traffic. D-ITG is a platform capable to produce traffic at packet level accurately replicating appropriate stochastic processes for both IDT (Inter Departure Time) and PS (Packet Size) random variables (exponential, uniform, cauchy, normal, pareto). D-ITG is capable to generate traffic at network, transport, and application layer. For the background traffic we generated UDP, TCP and both UDP and TCP flows simultaneously. For emulating VoIP we generate 18 Bytes VoIP packets at a rate of 89 packets per second, which gave this flow a bandwidth of 128Kbps. We used exclusively udp, tcp and then mixing two of these in equal share to get the varying contention from the background traffic. On the other end the counterpart utility server was listening on the port where VoIP packet would have arrived. From all the different runs we got the following statistics: a) average delay, b) average jitter, c) observed throughput, d) of packets lost and e) delay variation For our Access Point and Clients we used desktop PC s running Linux Red Hat 9. with the HostAP device driver and LinkSys cards. The HostAP drivers allowed us to configure a wireless card and a standard computer as an access point. This setup allowed us to run the necessary tools to run our test as well as configuring the different packet scheduling (queuing disciplines) using tcng (traffic control next generation) and qdisc (scheduler). The tcng and qdisc tools allowed us to configure our network interfaces under a Linux environment and test the FIFO, PFIFO and SFQ disciplines. A brief description of this disciplines is given on the next sections. 4.1 First in first out (FIFO) This is the trivial most way of queuing. It only serves packets on the order of their arrivals, does not do any reshaping and rearranging of packets 4.2 Priority FIFO (PFIFO) It consists of three FIFO with first band having higher priority over the others. So packet of band 1 is emptied before band 2 (if diferent traffic with QoS requirements existe then multiple queues will be served). 4.3 Stochastic Fair Queuing (SFQ) Its a simple implementation of the fair queuing algorithms family. Here traffic is divided in to very large number of queues. Traffic is then sent in a round robin fashion, giving each session/flow the chance to send data in 4
turn. It does not allocate a queue for each session. It has an algorithm which divides traffic over a limited number of queues using a hash function. Applicability of SFQ is best realized when there is a multiple other flows contending for the channel. 5 Results We conducted experiments, for different types of background traffic and loads, to compare the performance of the three queuing disciplines. Our intention in these tests was to stress the system and see how it behaves and comparing the results. For these experiments we created TCP, UDP and TCP+UDP background traffic. The graphs show the maximun delay, average delay, delay variation, packet loss and delay jitter vs. number of contending flows. For the test of UDP or TCP as a background traffic we assigned 1Mbps of Bandwidth to each of the contending flows. For the test of combined TCP and UDP background traffic, the contending flows are of 5Kbps. For this combination of flows (TCP+UDP) the number of flows is simetric, meaning by this that a one flow means 1 UDP and 1 TCP flows, a two flows means 2 UDP and 2 TCP flows, etc. The figures show bellow compare the performance between the packet scheduling we are proposing (PFIFO) and the Stochastic Fair Queuing (SFQ) discipline. 6 Results Analysis Delay and Delay Jitter Fig 1 to Fig 6 shows that the PFIFO discipline outperforms the SQF and FIFO disciplines in terms of delay. Similarly, Fig 1 to Fig 12 shows that PFIFO performs the best in delay jitter terms. Furthermore, for the PIFO discipline, the jitter and delay remains almost constant when increasing the background load (number of contending flows). These performance results where expected since the PFIFO discipline will always serve first the VoIP traffic regardless of the number of contending flows or the data rate they are using. On the other hand a fair discipline as SFQ will assign an equal share to every flow, hence when the number of contending flows increase less serving time will be assigned to the VoIP traffic. The Figures indicate that for moderate UDP background traffic the per packet jitter remains almost constant for both all disciplines. 5
35 3 45 4 35 25 3 Average Delay (msec) 2 15 1 Average Delay (msec) 25 2 15 1 5 5-5 1 2 3 4 5 6 7 8-5 1 2 3 4 5 6 7 8 Fig 1. Average Delay vs. UDP Background Traffic Fig 2. Average Delay vs. TCP Background Traffic 6 5 8 7 p 4 6 Average Delay (msec) 3 2 Maximun Delay (msec) 5 4 3 1 2 1-1 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Fig 3. Average Delay vs. TCP+UDP Background Traffic Fig 4. MAX Delay vs. UDP Background Traffic 1 9 p 12 p 8 1 7 8 Maximun Delay (msec) 6 5 4 3 Maximun Delay (msec) 6 4 2 2 1 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Fig 5. MAX Delay vs. TCP Background Traffic Fig 6. MAX Delay vs. TCP+UDP Background Traffic 6
6 p.5.45 p 5.4 4.35 Packet Loss (%) 3 Packet Loss (%).3.25.2 2.15 1.1.5 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Fig 7. Packet Loss vs. UDP Background Traffic Fig 8. Packet Loss vs. TCP Background Traffic 4 35 p 14 12 p 3 1 Packet Loss (%) 25 2 15 Average Delay Jitter(msec) 8 6 1 4 5 2 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Fig 9. Packet Loss vs. TCP+UDP Background Traffic Fig 1. Avg Delay Jitter vs. UDP Background Traffic 16 14 p 18 16 p 12 14 Average Delay Jitter(msec) 1 8 6 Average Delay Jitter(msec) 12 1 8 6 4 4 2 2 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Fig 11. Avg Delay Jitter vs. TCP Background Traffic Fig 12. Avg Delay Jitter vs. TCP+UDP Background Traffic 7
7 Conclusion We have show that our packet scheduler perform better than other fair queuing disciplines and can provide an adequate level of QoS for voice transmissions over 82.11 WLAN s. Our scheduler outperforms SQF (Stochastic Fair Queuing) in delay, jitter and packet lost. In addition to this, since the VoIP traffic is in the order of a few tens of Kbps the other flows with less priority will not starve while the queuing delay of the VoIP packets on the network layer will be minimized. Also, it is evident that no other priority scheduling mechanism will perform better in terms of VoIP packet queuing delay. In addition to this, using OPNET, we simulated the expected performance of 82.11b MAC layer when there are numerous contenders. References [1] The IEEE82.11 Standard http://standards.ieee.org/getieee82/download/82.11b- 1999.pdf [2] IEEE Draft Std 82.11e, Medium Access Control (MAC) Enhancements for Quality of Service (QoS), D2.a, November 21. [3] D. Chen, S. Garg, M. Kappes, K. S. Trivedi, Supporting VoIP Traffic in IEEE 82.11 WLAN with Enhanced Medium Access Control (MAC) for Quality of Service, Tech Report August 22 [4] A. Kopsel and A. Wolisz. Voice transmission in an ieee 82.11 wlan based access network. Proceedings of the 4th ACM international workshop on Wireless mobile multimedia, Italy, July 21 [5] Avesh Kumar et al. QoS Enabled Access Point, Project ECE 791V, Spring 23 [6] S. Mangold, S. Choi, P. May, O. Klein, G. Hiertz, and L. Stibor. IEEE 82.11e Wireless LAN for Quality of Service, IEEE Wireless Communications, Special Issue on Evolution of Wireless LANs and PANs, vol. 1, no. 6, December 23 [7] Linux Advanced Routing and Traffic Control www.lartc.org [8] Iperf: Internet Performance and Measurement Tool. http://dast.nlanr.net/projects/iperf. [9] RUDE http://rude.sourceforge.net [1] D-ITG, Distributed Internet Traffic Generator http://www.grid.unina.it/software/itg/ 8