Admission Control for VoIP Traffic in IEEE 802.11 Networks

Admission Control for VoIP Traffic in IEEE 802.11 Networks Sachin Garg Avaya Labs Basking Ridge, NJ 07920 Email: sgarg@avaya.com Martin Kappes Avaya Labs Basking Ridge, NJ 07920 Email: mkappes@avaya.com Abstract In this paper, we propose a metric for measuring the utilization of an IEEE 802.11b wireless network and outline how this metric can be accurately estimated using data that is readily available in most Access Points. We furthermore describe how this metric can be used to perform admission control for VoIP traffic and describe experiences with a prototype implementation. Admission control for VoIP traffic in 802.11 networks is necessary since the number of simultaneous VoIP connections in a single cell of an 802.11 network is very small. I. INTRODUCTION As converged networking in the wired world gains foothold, it is likely that wireless networks, specifically, Wireless LANs (802.11) will also be increasingly used for voice traffic. The maximal data rate of 802.11b networks is 11 Mbps (other possible data rates are 1, 2 and 5.5 Mbps). Experiments in [6] as well as theoretical calculations in [7] show that at this rate, the maximal throughput achievable is approximately 6.2 Mbps for data traffic. The maximal throughput when using only VoIP traffic can be as low as 800 Kbps using a typical VoIP codec (G711 with 10ms audio data per packet). Consequently, the maximal number of simultaneous VoIP calls that can be placed in a cell is only between two and six, depending on the average data rate. An analysis of the maximal number of simultaneous VoIP connections over 802.11a and 802.11b networks can be found in [7]. As experiments in [6] also revealed, placing an additional call or an additional data connection that exceeds the capacity of the wireless network will result in unacceptable call quality for all ongoing VoIP calls. Further, if the load offered to the network is higher than its capacity, the DCF medium access scheme of 802.11 curtails the client with the highest load first. In most cases, the access point of the wireless cell puts more traffic on the air than the associated stations. Hence, it gets curtailed first which leads to unacceptable packet loss for all VoIP streams transmitted from the access point to a client resulting in bad call quality for all connections. Thus, taking into account the low number of VoIP connections possible, the need for VoIP admission control is apparent. II. THE CHANNEL UTILIZATION ESTIMATE (CUE) For measuring network resource usage, the traffic on the wireless network is partitioned into flows, using transport layer information if possible. A Transport Layer flow is uniquely determined by the 4-tuple (sourceip,dstip,srcport,dstport) and by the Transport Layer protocol type of the flow, namely TCP or UDP. Given two communicating stations, this classification scheme implies that the channel utilization is measured separately for each traffic direction. A TCP connection results in two TCP flows and a VoIP call consists of two UDP flows. In other words, this separation captures the asymmetric nature of most data connections, such as file/web downloads in terms of channel utilization. A frame is classified based on a lower layer criteria (IP or MAC) only if the higher layer information is unavailable or if the packet/frame belongs to a specific layer. Apart from flows associated with voice and data traffic, we also consider auxiliary flows. Auxiliary flows represent network activities such as erroneous transmissions and collisions and typically represent wasted network capacity. In 802.11 wireless networks, the channel utilization of a flow and the remaining network capacity cannot be measured by bandwidth. Consider an 802.11b wireless infrastructure based network with a single client. In this case, the fixed overhead per frame transmission is 765µs at 11 Mbps regardless of the payload size. For 100 byte payload, the maximum transmission rate achievable is 1193 frames/second, resulting in a throughput of 954 Kbps. For 1000 bytes payload, a maximum of 670 frames can be transmitted per second, resulting in 5.36 Mbps throughput (for details, see [6]). Hence, questions like can the network accommodate a new flow with 2 Mbps bandwidth or can the network accommodate 800 packets per second cannot be answered without additional information. The situation becomes more complex when multiple flows from different stations operating at different data rates are to be considered in determining channel utilization. We propose to use the fraction of time per time unit needed to transmit the flow over the network as indicator for the network resource usage of a flow. We call this measure channel utilization estimate (CUE). In the remainder of this paper, we will base our considerations on a per second basis. The choice is arbitrary. Any other interval, such as a beacon-period could be used without any change in the results. Figure 1 shows the CUE as a function of packet-size for some fixed values for the bandwidth for a single client sending at 11 Mbps. As can be seen, the CUE of a flow can range almost anywhere from 0 to 1 for a given fixed bandwidth even when the data rate is constant. This figure underscores the need

TRANSMISSION TIME TO ACCOUNT FOR 1 0.9 0.8 0.7 SIFS DIFS BACKOFF SIFS DIFS CUE 0.6 0.5 0.4 0.3 0.2 0.1 0 1 51 101 151 201 251 301 351 401 451 501 551 601 651 701 751 801 851 901 951 1001 1051 1101 1151 1201 1251 1301 1351 1401 1451 Packetsize [bytes] 64 Kbps 500 Kbps Fig. 1. CUE as a function of packet-size for fixed bandwidths in the scenario of a single client sending at 11 Mbps. for using CUE instead of bandwidth for assessing the capacity of a wireless network. As example, consider a flow with 154 (1000) size frames having a bandwidth of 123.2 Kbps (1 Mbps) and transmission parameters as outlined above (the first parameters are those of a VoIP stream of an ITU G711 codec with 10ms of audio data per packet as seen on the MAC layer). Then the time (overhead and actual data transmission time) to transmit a single frame is 877µs (1492µs). Transmitting 123.2 Kbps (1 Mbps) using a frame size of 154 (1000) bytes requires 100 (125) packets per second. Transmitting 100 (125) packets of that size takes 87.7ms (186.5ms). Hence, the CUE of the flow is 0.0877 (0.1865). The CUE of a flow is the fraction of time the network is busy transmitting data for that flow. The sum of CUEs of all flows (including auxiliary flows) is the fraction of time the medium is busy. This will be referred to as CUETotal. For a fully loaded medium, CUETotal = 1. Hence (1 CUETotal) is the fraction of medium idle time in the measured time interval. A new flow can be accommodated without sacrificing other flows in the network if its CUE is going to be smaller than this value. The CUE of a single flow can indeed get very close to one. We achieved a CUE of 0.993 for a single flow of UDP data constantly sending out frames to the network in a single client scenario. The experimental setup is identical to the one described in [6]. The difference to 1 is due to MAC- Level exchange of information such as beacons and other management frames which is captured in other flows. III. MEASURING THE CUE In this section, we examine how CUE can be measured for flows in infrastructure 802.11b networks. In the process, we demonstrate that most of the data needed to be known for computing (or accurately assessing) the CUE of a flow is readily available in the access-point. For space reasons, we will focus on transmissions using the standard DCF MAC scheme. However, it is straightforward to extend this approach to special cases such as the use of RTS/CTS or fragmentation. Furthermore, this approach can also be used in conjunction 1 Mbps 2 Mbps 3 Mbps 4 Mbps 5 Mbps 6 Mbps OTHER FRAME Fig. 2. ACK DATA FRAME ACK IEEE 802.11 CSMA/CA medium access scheme. with the QoS-enhanced edcf MAC scheme as proposed in the current draft of the IEEE 802.11e standard for QoS in wireless networks. It is straightforward to monitor packets per second, used bandwidth and average packet size per flow as outlined in [5]. For regular Ethernet, these three parameters would be sufficient to compute the transmission time per packet. For 802.11 networks, however, the overhead due to the channel access mechanism is not captured in any of the parameters. In fact, this overhead is substantial and cannot be ignored. A pictorial presentation of the mechanism and the transmission time for a frame is shown in Figure 2. The detailed description of the Distributed Coordination Function (DCF) can be found in the 802.11 standard [8]. Let R denote the data rate in bps and b the size of the data frame in bytes. Then, the time needed for transmitting the frame can be computed as shown in the table below. Part Time [s] Data Frame 192µs + b 8/R SIFS 10µs ACK 192µs +14 8/R DIFS 50µs Apart from frame size, the only information needed to calculate the tabulated values is the data rate. The component of the transmission time not addressed so far is the back-off value as shown in the above figure. The back-off mechanism is used in 802.11 to avoid the collision of frames and is a multiple of the so-called slot time which happens to be 20µs in 802.11b. We will discuss how these values can be estimated if they cannot be exactly determined in the next section. To accurately determine the CUE of a flow, it is sufficient to compute the transmission time of all frames transmitted that belong to the flow and then sum up these values on a per-second basis. However, it is not difficult to see that the exact CUE of a flow may also be computed by multiplying the number of frames per time unit with the average transmission time for a frame of the flow. In particular, the CUE of a flow can be computed using the number of frames sent n, the average number of bytes sent per data frame b, the average data rate (on a per-byte basis) R avg and the average number of actual back-off slots waited before transmission s. In summary, all parameters but data rate and average actual back-off are collected in the AP and can be obtained from it by standard means (such as SNMP MIBs). IV. ESTIMATING THE CUE So far, we have described how to calculate the CUE values for the flows in the network and for any additional traffic. time

As often happens in computer systems, there is a tradeoff between accuracy and the amount of information that needs to be collected. By keeping track of the traffic and its characteristics, an AP can get a totally accurate picture of the CUEs of flows and auxiliary flows in the wireless network. In practics, it may be simpler to estimate some values. We shall now describe methods for estimating the data rate and the average actual back-off. We will also show how potential errors in such estimations can be mitigated. The data rate of a transmitted frame can be observed by both the receiving and the sending party. As all traffic in an infrastructure-based network either originates from the AP or is destined to it, it seems feasible to get accurate information about the actual data rate of a particular frame and thus also of the average data rate of a particular flow from the Access Point. The data rate is determined by the wireless station based on factors such as frame error rates, strength of the radio signal etc. and is not dependent on the characteristics of a flow. In fact, all flows emanating from a station will use the same data rate at a given point in time. Therefore, it suffices to measure this parameter on a per-station basis and use the value for all flows from that station. So, instead of recording the data rate of every frame, it may be sufficient to compute the average transmission speed based on sampling frames in a short period such as a beacon-period. If this is not possible, most Access Points today expose the current data rate of traffic from and to a station. This value can also be used for an estimation. Determining the actual back-off before transmission on a per-frame basis is not possible for anyone but the station transmitting the frame. An observer on the channel cannot distinguish between idle times caused on the channel because of back-off slots before a transmission versus the idle time caused as the station did not attempt to transmit at all. Fortunately, for our purposes the average back-off value on a per-second basis is of interest. Due to the fair nature of DCF, the average back-off experienced by any station in the network is identical. In other words, the average back-off can be measured at the access-point only and the same value can be used for all stations. Like before, it may suffice to measure average back-off based on few random samples at the accesspoint in a fixed duration. If the average actual back-off cannot be measured at the AP, it may also be estimated based on the number of active stations in the network. As the preceding discussion shows, the values necessary to determine the CUE of a flow can either be derived by standard means or accurately estimated even without having full access to the PHY/MAC layers of an AP. In fact, we believe that there is a spectrum of possibilities trading off accuracy against simplicity of data collection. For instance, the prototype described in Section VI computes CUEs on a per-station basis that are then attributed to individual flows. As the average actual back-off and the average data rate vary only on a per-station, not per-flow basis, this approach does not dilute accuracy. Although it is possible to measure the CUE of Layer 2 traffic and of collisions and erroneous transmissions, these network activities can also be taken care of by defining an adjustable parameter CUETotalMax that can range from zero to one and would typically be slightly less than one. This parameter defines the de-facto limit of the network. By adjusting this parameter, our scheme could easily adapt either for unusual situations such as extremely high frame loss due to interference. Furthermore, it could be used to adjust the scheme in case the CUEs for flows are not accurately computed but estimated. In the following, we outline one particular use for CUETotalMax, namely for mitigating errors resulting from (deliberately) inaccurate estimations. We will illustrate this concept by describing how collisions can be taken into account without actually measuring them and without using auxiliary flows as outlined earlier by adjusting CUETotalMax instead. Due to the nature of the MAC protocol, once in a while two stations will attempt to transmit a frame at the same time resulting in a collision. As the data involved in a collision is rendered useless, we need to account for the CUE of collisions i.e. the fraction of time per time unit wasted by collisions. Previous analysis as well as our own simulation results indicate that when 10 stations simultaneously transmit, a very unlikely scenario, the collisions waste about 15% of the network capacity. The easiest way to accommodate collisions into our model is to adjust the CUETotalMax value from 1 to.85. With reasonable safety we may assume that actual collisions will not exceed that value and thus that if CUETotal is less than CUETotalMax all flows can be transmitted without loss or curtailment due to exceeding the network capacity. Whereas this approach is elegant and simple, in most cases the CUE wasted by collisions will be less than 15% and hence some capacity of the network would remain unused. Therefore, a more accurate estimation of the collisions would be beneficial. As extensive simulation studies have shown [1] [2] [3] [4], the number of collisions is a function of the number of clients associated with an AP and their traffic characteristics. For instance, the collision rate is known to be just 3% when an 802.11b network is used up to its capacity for VoIP traffic only [7]. Hence, we could tabulate those values and then estimate the CUE of the wasted channel capacity by looking up those values. This would allow for a more precise treatment of collisions. In fact, one could think of a large variety of schemes and situations how to use CUETotalMax along the lines indicated here. Whereas the previous example considered inaccuracies that were deliberately placed into the system by simplifying some part of the data collection process, CUETotalMax can also be used to provide backup network capacity that may be needed in conjunction with VoIP. This will be explained in more detail in the next section. V. USING CUE FOR ADMISSION CONTROL In the following, we describe how CUE can be used for admission control for VoIP traffic in wireless networks. Although our admission control scheme could be extended to

other scenarios as well, we will focus here on one only two classes of flows, namely VoIP flows and data flows. For VoIP flows, the bandwidth and other traffic characteristics of the flow do not change during the lifetime of the flow, and the CUE of the flow can be accurately determined when the flow is detected. For data flows, the bandwidth and other traffic characteristics may change over time, and the CUE of the flow cannot be estimated in advance. The key difference between VoIP and data flows is that data flows may be curtailed (almost) arbitrarily and still be useful whereas VoIP flows need to be given the full resources they need if they are admitted to the network. Hence, admission control for VoIP flows is necessary whereas traffic control is sufficient for data traffic. In the following, we will discuss how to determine the permissibility of a new VoIP flow. By our terminology, a new flow is a flow that is new to the wireless network. A new flow need not be one that has just been established but could be an ongoing flow from or to a station that has just roamed into this cell of the wireless network. While the question how a flow can be detected is beyond of the scope of this paper, we would like to mention that a flow can be detected by observing the first packet from that flow. This holds for a flow that is about to be established as well as an ongoing flow that just roamed into the cell. VoIP streams can be detected before they are actually established by monitoring for traffic to initiate the call, for instance packets directed to a H.323 port or Packets containing SIP protocol messages. Similarly, the start of TCP flows can be detected by examining the SYN/ACK bits in the TCP packet header. The key point is that a flow cannot create significant load on the network before it is detected. In this section, we show how CUEs can be used for admission control for VoIP in wireless networks. The actual policies however are not subject of this paper. Therefore, we will present a somewhat more abstract presentation of how the permissibility of a flow is computed. The steps for a newly detected VoIP-flow are as follows. CUETotal is computed and the CUE for the new VoIP-flow is estimated. If CUETotal plus the CUE for the new flow is less than CUETotalMax, the VoIP flow is admitted. If not, depending on the policies a decision whether data flows are to be curtailed for the new flow or not is made. If so, the restrictions for the data flows are calculated and enforced and the new flow is admitted. The question how data flows can be curtailed is out of the scope of this paper. For a presentation of such mechanisms, please see [5]. Clearly, calculating the CUEs as described above generates accurate data of the usage of the network in a past interval. Our assumption is that the past CUE of a flow constitutes a good estimate of the flows future CUE. In other words, we assume a steady state usage model for computing the permissibility of a new VoIP flow. As in fact the bandwidth used by a flow may change over time, it is necessary to enforce bandwidth restrictions for non-voip flows in order to provide VoIP admission control. This holds especially true if the network operates close to its capacity limits. Along the same lines, when a new data flow is detected, the CUE available for this flow is to be determined and enforced depending on the policies in the system. While the CUE of a flow accurately measures the network resources the flow uses, we think that bandwidth is a variable that will probably also be taken into account for formulating admission control policies. Apart from determining the question whether new flows should be admitted or not, the CUEs of all flows need to be monitored constantly. As we pointed out earlier, data flows may be curtailed and still be useful whereas VoIP flows need to be given the full resources they desire. Whereas the bandwidth of a VoIP flow typically remains fixed during the lifetime of a connection, the CUE of the same connection may change for various reasons. To mention one, the VoIP endpoint in the wireless network may be mobile and roam away from the AP such that the signal strength fades and the transmission speed of the data is decreased from 11 Mbps to 1 Mbps. As an example, transmitting a 314 byte frame (a characteristic size for a VoIP frame) in a single sender scenario takes 993µs at 11 Mbps and 3379µs at 1 Mbps. Consequently, the CUE of such a stream increases by a factor of approximately 3.4. However, users of VoIP connections expect the same behavior of VoIP connections as they do from usual telephony networks: A call that was successfully established is assumed to have acceptable quality for the duration of the call. Thus, a call requiring more resources should not be dropped but instead, the additional resources should be provided by the network. In a network mostly used for data connections, this increase in the CUE of a VoIP flow can be accommodated by further curtailing the CUE of data connections. However, problems can occur if the network is prevailingly used for VoIP. As no flow can be curtailed then, there is the need to have some network capacity reserve that could accommodate a change in data rate for some of the connections. As it is unlikely that all stations roam out of range at the same time, this reserve would probably be large enough if it consisted of sufficient CUEs for one or two slow bandwidth connections. We propose to adjust CUETotalMax in order to provide some backup capacity for such cases. However, whether such reserves need to be present or not is a question of policy. VI. PROTOTYPE IMPLEMENTATION We implemented a first prototype of a System computing CUEs on a Linux Laptop running RedHat 7.2. The prototype implementation leverages the Wireless Access Server (WAS) infrastructure as described in [5]. Figure 3 shows the highlevel setup of the system and how it is deployed in a typical enterprise network. Alternate configurations to this setup are possible. WAS consists of two components. The first component is a box, which sits between the wired network and the wireless-network. Specifically, the box sits at the edge of the wired network immediately behind the access-points. All traffic to/from an access-point traverses this box. This box, referred to as the Wireless Gateway (WG), acts as bridge with filtering capabilities at the IP and TCP/UDP layer. In other words, the Wireless Gateway may operate

Fig. 3. WAS High-level System Architecture. using 1472 bytes of payload per packet The CUE for this station is 0.18. As can be seen in the screen shot, the prototype also performs VoIP stream classification. For each identified stream, Codec settings, audio data per packet in ms and the CUE for the stream are shown. The prototype allows for call admission control by specifying a threshold value between 0 and 1. If CUETotal is below the threshold, new calls are accepted and otherwise rejected. The right side of the screen shot shows the bandwidth of the VoIP streams and the lower right half is used for manually curtailing data connections. For details on how data connections are throttled down, please see [5]. Fig. 4. Screenshot of Prototype Implementation. completely transparent to the clients in the wireless network. Multiple access-points could be bridged (connected) via a single gateway. This basic setup provides us with a platform for QoS, access control and other features for 802.11 networks. Note that the functionality proposed for WG need not be present in a separate box. In fact, we are planning to move the WAS functionality into an access point running embedded Linux. The second component of Wireless Access Server is called the Gateway Controller (GC). The GC may reside on any point of the wired network. The GC is responsible for controlling the behavior of the wireless gateway. In the prototype system, CUE values are computed in the Wireless Gateway by leveraging per-station traffic information as provided by the AP driver and per-flow information as collected in the wireless gateway. The CUE for individual flows is estimated based on these values. The average random back-off and average number of collisions is estimated based on the number of active stations in the wireless cell. The focus of our prototype is to demonstrate that it is possible to accurately assess the channel usage using CUE even with this very limited amount of data. Figure 4 shows a screenshot of the Gateway Controller when two stations are associated with the Access Point. One of the wireless stations (135.10.54.116) participates in a VoIP call using the G711-codec with 10ms of audio data per packet. The flow from this station to the wired side takes 8% of the channel capacity. The CUE of the reverse VoIP flow from wired to wireless is accounted for at the AP which also shows a CUE of 0.08. The other wireless station is transmitting a UDP stream to the wired side with a bandwidth of 1.2 Mbps VII. CONCLUSION AND FUTURE WORK In this paper, we introduced the Channel Utilization Estimate for accurately assessing the network capacity and network usage of a wireless local area network. While the definition of the metric is straightforward, it is an accurate measurement for channel usage and it can be accurately computed or estimated on a per-flow basis to assess the actual capacity a flow uses in a wireless network and presented a prototype implementation that computes CUEs on a per-station and per-flow basis and performs admission control for VoIP traffic based on this metric. We also presented a prototype implementation. Finally, we would like to mention that the approach outlined in this paper can be extended in a natural way to the QoSenhanced edcf MAC scheme as proposed in the current draft of the IEEE 802.11e standard for QoS in wireless networks. While the number of possible VoIP connection increases with the new standard, the need for VoIP admission control and accurate assessment of used network resources remains. We are currently working on simulations and a prototype implementation in conjunction with 802.11e. REFERENCES [1] G. Anastasi and L. Lenzini. QoS provided by the IEEE 802.11 wireless LAN to advanced data applications: a simulation study, In Wireless Networks, Vol. 6, pp 99 108, J.C. Baltzer AG, Science Publishers, 2000. [2] G. Bianchi. Performance Evaluation of the IEEE 802.11 Distributed Coordination Function. In IEEE Journal on Selected Areas in Communication, Vol. 18, No. 3, March 2000, pp. 535 547. [3] A. Heindl and R. German. Performance modeling of IEEE 802.11 wireless LANs with stochastic Petri nets. Performance Evaluation, 44 (2001), 139-164. [4] H. S. Chayya and S. Gupta. Performance modeling of asynchronous data transfer methods of IEEE 802.11 MAC protocol. In Wireless Networks Vol 3, 1997, pp. 217-234. [5] S. Garg, M. Kappes and M. Mani. Wireless Access Server for Quality of Service and Location Based Access Control in 802.11 Networks, Proceedings of the Seventh IEEE Symposium on Computers and Communication (ISCC 02), Taormina, Italy, 2002. [6] S. Garg and M. Kappes. An Experimental Study of Throughput for UDP and VoIP Traffic in IEEE 802.11b Networks, To appear in Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC) 2003, New Orleans, LA, 2003. [7] S. Garg and M. Kappes. CanIAddaVoIPCall?, To appear in Proceedings of the IEEE International Conference on Communications (ICC) 2003, Anchorage, Alaska, 2003. [8] IEEE 802.11, 11a, 11b standard for wireless Local Area Networks. http://standards.ieee.org/getieee802/802.11.html