A New Admission Control Metric for VoIP Trafc in 802.

11 Networks
Sachin Garg sgarg@avaya.com Avaya Labs Research 233 Mount Airy Rd. Basking Ridge, NJ 07920 Martin Kappes mkappes@avaya.com Avaya Labs Research 233 Mount Airy Rd. Basking Ridge, NJ 07920

Abstract In this paper, we propose a new metric for admission control of VoIP trafc for IEEE 802.11b networks. Due to the large xed overhead in IEEE 802.11b, the bandwidth available at the payload sizes typical for VoIP trafc is far less than the bandwidth available when using the network for data trafc. Hence, bandwidth is inappropriate as criterion whether or not a new VoIP stream or data stream can be accommodated without pushing the network over its throughput limit. We propose a new criterion called network utilization characteristic which allows to assess the available resources in the wireless network in an accurate way and show how it can be used for admission control.

1 Introduction
In the last few years, wireless networks based on the IEEE 802.11b standard have gained popularity and have been widely deployed in enterprises mostly to provide wireless data access from Laptops, PDAs, etc. to the wired infrastructure of the enterprise. They have also been deployed in public hot-spots such as airports, hotels, conference facilities etc., mainly for internet connectivity. The maximal data rate 802.11b currently supports is 11 Mbps (other possible data rates are 1, 2 and 5.5 Mbps). When sending data frames with this rate, the maximal throughput achievable in such a network is approximately 6.2 Mbps. For VoIP trafc, the maximal throughput achievable is approximately only 2 Mbps for typical audio payload size per RTP packet. The signicant difference is due to the large transmission overhead per frame which remains the same regardless of the frame size. Depending on the actual average transmission rate, the number of simultaneous VoIP calls in a cell 1 of the wireless network is between 4 and 17 with G711 codec with 30ms audio data per packet. For details, see [6].
1

we use the term cell for what is referred to in the 802.11 standard as Basic Service Set (BSS).

As converged networking in the wired world gains foothold, it is likely that wireless networks will also be increasingly used for voice trafc. Placing an additional call or an additional data connection that exceeds the capacity of the wireless network will likely 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 rst. In most cases, the access point of the wireless cell puts more trafc on the air than the associated stations. Hence, it gets curtailed rst 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. Experimental results in [6] show that the average delay incurred on the wireless link for VoIP connections is about 5ms and the average jitter is about 7-9ms even when the network load is low. These values are signicantly higher than in a wired environment, for instance, Ethernet. Hence, MAC layer improvements to lower the delay and jitter values, such as the proposal from the 802.11e taskgroup, are very important. Yet, any QoS strategy for networks, where the available network capacity is limited and likely to be exceeded with consequences for all connections needs to provide an accurate way of measuring the network capacity and of enforcing admission control. In fact, the methods for measuring network capacity and providing admission control outlined here could blend in well with 802.11e.

Denitions

2.1 Flows
The trafc on the wireless network is partitioned into ows. Each transmitted frame on the wireless network belongs to exactly one ow. The criterion could be frame/packet identiers at various network layers starting from the MAC Layer (Layer 2) up to the Transport Layer (Layer 4). A frame is classied based on a lower layer criteria only if the higher layer information is unavailable of the packet/frame belongs to a specic layer. For instance, ICMP packets are Layer-3 packets. Further, certain frames such as Beacons, probe-request and response frames are limited to Layer-2 only. In general, using higher layer criteria, if possible, provides ner granularity of classication. A Transport Layer ow is uniquely determined by the 4-tuple
0 !  !   !     !      ''&#" )('&"%$#" 

and by the Transport Layer protocol type of the ow, namely TCP or UDP. Given two communicating stations, this classication scheme implies that the network utilization is measured separately for each trafc direction. A TCP connection results in two TCP ows and a VoIP call consists of two UDP 2

ows. In other words, this separation captures the assymetric nature of most data connections, such as le/web downloads in terms of network utilization. Apart from ows associated with voice and data trafc, we also consider auxiliary ows. Auxiliary ows represent network activities such as erroneous transmissions and collisions which cannot be accredited to any particular ow but typically represent wasted network capacity.

2.2 Network Utilization Characteristic

We dene a new criterion called network utilization characteristic which allows to accurately assess the available resources in the wireless network. Before we come to the actual presentation of this measure, we will outline by example why bandwidth is an inappropriate criterion for measuring network utilization of wireless networks. In an 802.11b wireless infrastructure based network with a single client, the xed overhead per frame transmission is 765 s when transmitting at 11 Mbps. The time it takes to transmit 100 bytes at this data rate is 72.7 s. For details on how these values are obtained see [6]. Consequently, the transmission of 1000 bytes takes 727 s. Therefore, when transmitting 100 byte frames, the transmission of a single 100 byte frame including all overhead takes

s and thus the maximum number of frames

that can be transmitted per second is 1193, resulting in a maximal throughput of 954 Kbps. For 1000 bytes size per frame, a maximum of 670 frames can be transmitted per second, resulting in a maximal throughput of 5.36 Mbps. Hence, the simple questions can the network handle a ow with 2 Mbps bandwidth or can the network accommodate 800 packets per second cannot be answered without additional information. The situation becomes even more complex when multiple ows are to be considered as necessary for admission control. Therefore, we propose a measure called network utilization characteristic, which is measured on a per-ow basis. The network utilization characteristic (NUC) of a ow is dened as the fraction of time per time unit needed to transmit the ow over the network. Two ows having the same network utilization characteristic are said to be bandwidth equivalent. 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 can be used without any change in the results. First, we illustrate this concept by some examples. Consider a ow with 100 byte size frames having a bandwidth of 100 Kbps and transmission parameters as outlined above. Then the time (overhead and actual data transmission time) to transmit a single frame is 837 s. Transmitting 100 Kbps using a frame

0.9

0.8

0.7

0.6 NUC

0.5

0.4

0.3

0.2

0.1

0
1 51 10 1 15 1 20 1 25 1 30 1 35 1 40 1 45 1 50 1 55 1 60 1 65 1 70 1 75 1 80 1 85 1 90 1 95 1 10 01 10 51 11 01 11 51 12 01 12 51 13 01 13 51 14 01 14 51

Figure 1: NUC as a function of packet-size for xed bandwidths in the scenario of a single client sending at 11 Mbps. size of 100 bytes requires 125 packets per second. Transmitting 125 packets of that size takes 104.6 ms. Hence, the NUC of the ow is 0.1046. Now consider a ow with 1000 byte size frames having a bandwidth of 1 Mbps and the transmission parameters as outlined above. The ow sends 125 frames per second and the transmission time for a single frame is 1492 s. Hence, the NUC of the ow is 0.1865. Figure 1 shows the NUC as a function of packet-size for some xed values for the bandwidth for a single client sending at 11 Mbps. As can be seen, the NUC of a ow can range almost anywhere from 0 to 1 for a given xed bandwidth. This gure stresses the necessity for using NUC instead of bandwidth for assessing the capacity of a wireless network. Summing up the NUCs of all ows (including auxiliary ows) in the network yields the fraction of time the network is busy. Consequently, the difference between one and the sum is the time the medium is idle. A ow can be accommodated without sacricing other ows if its NUC is going to be smaller than this value.

3 Measuring Network Utilization Characteristic

In this section, we examine how NUC can be measured for ows in infrastructure 802.11b networks that operate based on DCF. In the process, we demonstrate that the data needed to be known for computing (or accurately assessing) the NUC of a ow is readily available in the access-point. Specically, two parameters are needed for determining the NUC of a ow, namely the the number of frames sent for

% $ # ) " % $ # ) "& % $ # ) " % $ # ) "1 % $ # ) "0 % $ # ) "( % $ # ! ' ' "& % $ # ! "      

SIFS

DIFS ACK

BACKOFF

Figure 2: IEEE 802.11 CSMA/CA medium access scheme. that ow per second and the average transmission time for a frame. It is straigthforward to monitor packets per second, used bandwidth and average packet size per ow as outlined in [5]. For regular Ethernet, these three parameters would be sufcient 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. We now briey describe the Collision Avoidance (CSMA/CA) medium access scheme according to the Distributed Coordination Function (DCF) of the 802.11 standard [7] in order to explain the associated overhead. The MAC protocol is designed to prevent collisions from occurring. Furthermore, unicast frames are acknowledged by the receiving station. The acknowledgment (ACK) is sent out after the transmission has nished and a certain duration of time called short inter frame spacing (SIFS) has elapsed. If a node wants to transmit a frame and senses the medium idle for a certain duration of time called distributed coordination function inter frame spacing (DIFS), it may start transmitting. As DIFS is longer than SIFS, it is made sure that a correctly received frame can always be acknowledged before the next frame is transmitted. If a node wants to start transmitting while the medium is busy or if it wants to transmit another frame after just nishing a transmission, it also waits for the medium to be idle for the DIFS period. Then, the node does not begin to transmit immediately but enters a contention phase for the medium. Contention is done by choosing an integer random back-off from a certain interval. The random backoff determines the number of time slots the client defers its transmission in addition to the DIFS time. If the medium is sensed idle in such a slot, the back-off timer is decreased by one. If the random back-off has decreased to , the node starts transmitting. If another node starts transmitting before this happens, the node continues to count down the back-off timer after the medium has been sensed idle for the DIFS period. Thus, if multiple clients want to transmit a frame, the one with the lowest random back-off time will win the contention for the medium.
'

 & %  "   !     $ # #  ! !  
SIFS DIFS ACK

  

     

time

Table 1: Transmission time for a frame without back-off.

3.1 Determining Transmission Time of a Frame

Transmission time of a frame consists of time to transmit the frame itself, PHY layer header overhead, overhead of an ACK and overhead imposed by the DCF mechanism. The DCF overhead consists of one SIFS, one DIFS and a back-off interval as illustrated in Figure 2. Sending ACKs and data frames causes a physical layer overhead of 192 s in each case. The duration of sending the data is depending on the frame length and the transmission speed. For an ACK, the size is 14 bytes xed so the duration only depends on the transmission speed. Furthermore, the intervals for SIFS and DIFS are xed. Let R denote the transmission speed in bps and

the size of the data frame in bytes. Then, the time needed

for transmitting the frame can be computed as shown in Table 1. Apart from frame size, the only information needed to calculate the tabulated values is the transmission speed. The component of the transmission time not addressed so far is the back-off value. As our perspective is the usage of the wireless medium, we are not interested in the actual back-off window that was chosen for the transmitted frame but in the actual number of idle back-off slots immediately preceding the transmission. A slot time in 802.11b is 20 s, so the number of slots waited between the end of DIFS and the transmission multiplied by the slot time yields the desired value.

3.2 Determining the NUC of a Flow

To accurately determine the NUC of a ow, it is sufcient to compute the transmission time of all frames transmitted that belong to the ow and then sum up these values on a per-second basis. However, let us start with a simplied methodology for computing the NUC of a ow. If the number of frames sent , the average number of bytes sent per data frame , the average transmission speed (on a per-byte basis) and the average number of actual back-off slots waited before transmission

are given, the NUC

can be computed as
0 '

'

# !  $$(

 

  

  

 

  
' &

& ' '

Part Data Frame SIFS ACK DIFS

Time [s]

# !  $"(

'

&

'

%

# ! $" 

Note that the NUC obtained is identical with the number which would be computed by summing up the transmission time needed for all frames of the ow. Whereas the number of frames sent per second and the average number of bytes sent per data frame can be obtained by standard means (such as SNMP MIBs), the transmission speed can be observed by both the receiving and the sending party. As the admission control scheme is most likely to be implemented in the access point and as all trafc in an infrastructure-based network either origins from the AP or is destined to it, it is feasible to get accurate information about the actual transmission speed of a particular frame and thus also of the average transmission speed of a particular ow. The transmission speed 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 ow. In fact, all ows emnating from a station will use the same transmission speed at a given time. Therefore, it sufces to measure this parameter on a per-station basis and use the value for all ows from that station. Moreover, instead of recording the transmission speed of every frame, it may be sufcient to compute the average transmission speed based on sampling frames in a short period such as a beacon-period. Determining tha 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 because the station did not attempt to transmit at all. However, for our purposes, we are interested in an average back-off value on a per-second basis. Due to the fair nature of DCF, the average back-off experienced by any station is the same. In other words, the average back-off can be measured at the access-point and the same value used for all stations. Like before, it may sufce to measure average back-off based on few random samples at the access-point in a xed duration. As the preceding discussion shows, the values necessary to determine the NUC of a ow can be easily derived by standard means or accurately estimated even without having full access to the PHY/MAC layers of the AP. In fact, we believe that there is a spectrum of possibilities trading off accuracy against simplicity of data collection. For instance, in order to assess the aggregated NUC of all ows in the network, it is sufcient to know the number of packets sent, the bytes sent, the average transmission speed in the network and the average actual back-off. While we only addressed how to compute or estimate the NUC of ows, it is also apparent that the data needed to compute the NUC of auxiliary ows, for instance due to collisions or erroneous transmissions, is present in the AP. For other ways of accounting for such trafc, see Section 4.1.

4 Using NUCs for Admission Control

In the following, we describe how NUCs can be used for admission control for VoIP trafc in wireless networks. The NUC of a ow is the fraction of time the network is busy transmitting data for that ow. The sum of all NUCs of all ows (including auxiliary ows) is the fraction of time the network is busy transmitting the data for all ows. We will refer to the sum of all NUCs of all ows (including auxiliary ows) as NUCTotal. If the medium is constantly busy transmitting data of the ows, NUCTotal equals one. Hence, the difference between one and NUCTotal is the fraction of time the medium has been idle in the measured time interval. From a theoretical and also from a practical perspective the NUC of a ow can indeed get very close to one. We achieved an NUC of 0.993 for a single ow 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 ows. Although it is possible to measure the NUC of Layer 2 trafc and of collisions and erroneous transmissions, these network activities can also be taken care of by dening an adjustable parameter NUCTotalMax that can range from zero to one and would typically be slightly less than one. This parameter denes 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 or it could be used to adjust the scheme in case the NUCs for ows are not accurately computed but estimated. In fact, whereas an accurate computation of the NUC of a ow is feasible, we envision that most systems would trade off accuracy against other factors. Let us now describe how these values can be used in order to determine the permissibility of a new ow. Although our admission control scheme could be extended to other scenarios, we will focus here on one where only two classes of ows are present, namely VoIP ows and data ows. By our terminology, a new ow is a ow that is new to the wireless network. A new ow need not be one that has just been established but could be an ongoing ow from or to a client that has just roamed into this cell of the wireless network. While the question how a ow can be detected is out of the scope of this paper, a ow can be detected by observing the rst packet from that ow. VoIP streams can be detected by monitoring for trafc to initiate a call, for instance packets directed to a H.323 port or Packets containing SIP protocol messages. Similarly, the start of TCP ows can be detected before they are established by examining the SYN/ACK bits in the TCP packet header. The key point is that a 8

ow cannot create signicant load on the network before it is detected. VoIP ows consist of real-time audio data. Such ows typically use connection-less transport layer protocols, in particular UDP, that do not guarantee the delivery of sent audio data information. In other words, lost packets are not retransmitted. Furthermore, the amount of trafc that the sender is transmitting to the receiver is xed for the duration of the ow. Thus, it will not be inuenced by parameters such as current load conditions of the network as indicated by e.g., lost packets or ICMP messages. Although losing some packets once in a while does not render the ow useless, the loss of more than 1% of the data usually deteriorates the quality of the ow to an unacceptable level. This in turn implies that curtailing such a ow by dropping a certain percentage of the packets renders the whole ow useless. Therefore, such a ow must either be given the full bandwidth it requires or be completely dropped. The bandwidth such a ow needs can be easily detected either by transparently examining the messages exchanged between the endpoints of the ow during connection setup time or by just observing the trafc patterns. As the average transmission speed of all clients in the wireless network and the average actual back-off are known, the NUC for that ow can be accurately estimated. It should be noted that while the number of frames and the size of the sent frames remains constant during the lifetime of the ow, the NUC of such a ow can change signicantly due to variations in the transmission data rate, especially in the case of mobile clients. We will discuss how to deal with this situation in the following section. Data ows, on the other hand, use connection-oriented transport layer protocols such as TCP. In most cases such protocols also provide ow control and congestion control. Apart from resending lost data, ow control and congestion control adapt the network usage of the connection due to current conditions such as available buffer size on the receiving side or network congestion. In other words, the bandwidth used by such a ow as well as its NUC can change over time. Whereas the user may notice a smaller bandwidth e.g., by longer transmission time for a le or web page, a reduction in bandwidth does not render the ow useless. Therefore, such ows can be throttled down by means such as TCP congestion control. The use of TCP congestion control and other mechanisms to curtail the bandwidth of such a ow is described in [5]. As opposed to VoIP ows, the bandwidth of a data ow cannot be assessed from the values collected when the ow is detected. In what follows, we assume that no information about the NUC of the ow is available. Table 2 summarizes the difference between VoIP and data ows. The goal of this paper is to show how NUCs 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

NUC Bandwidth and other trafc characteristics Curtailment

VoIP Flow Can be accurately determined when ow is detected Do not change during the lifetime of the ow Flow must either be given full NUC needed or must be shut down

Data Flow Cannot be determined when ow is detected Do change during the lifetime of the ow Flow can be curtailed (almost) arbitrarily. Flow restrictions are changed over time.

Table 2: Comparison between VoIP and data ows. somewhat more abstract presentation of how the permissibility of a ow is computed. The steps for a newly detected VoIP-ow are as follows. NUCTotal is computed and the NUC for the new VoIP-ow are estimated. If NUCTotal plus the NUC for the new ow is less than NUCTotalMax, the VoIP ow is admitted. If not, determining on the policies a decision whether other ows are to be curtailed for the new ow or not is made. If so, the restrictions are calculated and enforced and the new ow is admitted. If not, the new ow is not admitted. Clearly, calculating the NUCs as described above generates accurate data of the usage of the network in a past interval. Our assumption is that the past NUC of a ow constitutes a good estimate of the ows future NUC. In other words, we assume a steady state usage model for computing the permissibility of a new VoIP ow. As in fact the bandwidth used by a ow may change over time, it is necessary to also enforce bandwidth restrictions of non-VoIP ows 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 ow is detected, the NUC available for this ow is to be determined and enforced depending on the policies in the system. While the NUC of a ow accurately measures the network resources the ow uses, we think that bandwidth is a variable that will probably also be taken into used in formulating policies for admission control. Apart from determining the question whether new ows should be admitted or not, the NUCs of all ows need to be monitored constantly.

4.1 Uses for NUCTotalMax

In this section, we are going to outline some particular uses for the NUCTotalMax value as dened above. We envision two main uses for NUCTotalMax, namely the use of this value to make up for

10

certain inaccuracies that might arise if data needed to determine the NUC of ows and auxiliary ows is only partially collected on one hand and the use for creating a network capacity backup that might be needed in some situations on the other.

4.2 Loss and Collisions

So far, we have investigated how to accurately calculate the NUC values for all ows in the network and for any additional trafc. However, there is a trade-off between accuracy and the amount of information that needs to be collected. By keeping track of the trafc and its characteristics, an AP can get a totally accurate picture of the NUCs of ows and auxiliary ows in the wireless network. But it might be that for simplicity reasons, e.g., only one out of ten packets is used for calculating these values and that the NUCs are estimated based on these samples or that auxiliary NUCs are not kept track of but estimated. We envision that the resulting inaccuracies can be elegantly mitigated by employing NUCTotalMax. As an example, we will show how collisions can be taken into account without actually measuring them and without using auxiliary ows as outlined earlier. Instead, the value NUCTotalMax will be adjusted. 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 NUC 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 even 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 NUCTotalMax value from

to

. With reasonable safety we may assume that actual collisions will not exceed that value and thus

that if NUCTotal is less than NUCTotalMax all ows can be transmitted without loss or curtailment due to exceeding the network capacity. Whereas this approach is elegant and simple, in most cases the NUC wasted by collisions will be less than 15 % and hence some capacity of the network would be wasted. Therefore, a more accurate estimation of the collisions would be benecial. 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 trafc characteristics. Hence, we could tabulate those values and then estimate the NUC 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 NUCTotalMax along the lines indicated here.

11

4.3 Backup Capacity

Whereas the previous case considered inaccuracies that were deliberately placed into the system by simplifying some part of the data collection process, we will now deal with uncertainty with respect to the bandwidth usage of real-time ows that cannot be eliminated by more detailed data collection. As we pointed out earlier, data ows may be curtailed and still be useful whereas VoIP ows need to be given the full resources they desire. Whereas the bandwidth of a VoIP ow typically remains xed during the lifetime of a connection, the NUC 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 s at 11 Mbps and


In a network mostly used for data connections, this increase in the NUC of a VoIP ow can be accommodated by further curtailing the NUC of data connections. However, problems can occur if the network is prevailingly used for VoIP. As no ow can be curtailed then, there is the need to have some network capacity reserve that could accommodate a change in transmission speed 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 sufcient NUCs for one or two slow bandwidth connections. However, whether such reserves need to be present or not is a question of policy.

5 Prototype Implementation
In the future, we are planning to implement admission control for VoIP connections in wireless networks by employing our Wireless Access Server (WAS) infrastructure as described in [5]. Figure 3 shows the high-level setup of the system and how it is deployed in a typical enterprise network. Alternate congurations to this setup are possible. WAS consists of two components. The rst component is a box, which sits between the wired network and the wireless-network. Specically, the box sits at the edge of wired network immediately behind the access-points. All trafc to/from an access-point traverses this box. This box, referred to as the Wireless Gateway (WG), acts as bridge with ltering capabilities at the IP and TCP/UDP layer. In other words, the Wireless Gateway may operate 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 12

a stream increases by a factor of approximately

s at 1 Mbps. Consequently, the NUC of such

Figure 3: High-level System Architecture. 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.

6 Computing NUC in Special Scenarios

In this section, we are going to explain how the NUC can be computed for ows in special scenarios. In particular, we will address the RTS/CTS scheme and how our scheme could help in implementations of the forthcoming IEEE 802.11e standard for QoS in 802.11. These examples are chosen in order to explain by example how NUCs can be calculated in special situations. The methods applied here also work in different scenarios such as fragmentation.

6.1 RTS/CTS
Apart from the standard DCF scheme in IEEE 802.11 standard [7] as outlined before, it also provides a Ready to Send / Clear to Send (RTS/CTS) extension that is particularly useful in wireless networks which might suffer from the hidden station problem. The channel usage of a single frame transmission with RTS/CTS is shown in Figure 4. As the standard species, the use of the RTS/CTS mechanism is specied on a per-station basis and each station can be congured to use RTS/CTS either always, never or only on frames longer than a specied length. Hence, if the policy of the sending station and the length of the sent frame is known, it can be determined whether RTS/CTS is used or not even without observing the transmission. The policy of the each station in the network can either be obtained by observing its behavior or by querying it from the station. 13

BACKOFF RTS

SIFS

SIFS

CTS

Figure 4: IEEE 802.11 CSMA/CA medium access scheme with RTS/CTS On a per-ow basis, the use of RTS/CTS can be estimated by the average size of frames belonging to the ow and the variation of it. As shown in Figure 4, the overhead added by RTS/CTS consists of two additional SIFSs and the overhead to transmit the 20 byte RTS and the 14 byte CTS frames. Similar to the values shown in
        %
'

Table 1, the transmission time for RTS and CTS amount to

respectively and are thus depending on the transmission rate. We treated the case of RTS/CTS in some detail as an example how the NUCs of ows can be accurately computed in other scenarios. In fact, this can be done for other special cases as well as for instance if fragmentation occurs. In contrast to Ethernet, fragmentation in wireless networks is in most cases not the result of a lower maximal frame size of the wireless link (the maximal frame size in 802.11 networks is far higher than in wired Ethernet) but in most cases done deliberately for improving interference stability of the wireless network. The use of fragmentation results in an overhead that is very similar to the one for RTS/CTS.

6.2 IEEE 802.11e

The forthcoming IEEE 802.11e standard will provide a new MAC scheme called Hybrid Coordination Function (HCF) that will combine a centralized polling scheme with a QoS-enhanced version of DCF called EDCF. As the standard is work in progress, we will not explicitly describe how the NUC of a ow as well as the overall utilization of the wireless network can be computed. However, we want to point out that it is feasible to do so. Most likely, 802.11e will provide a feature that stations can request time-bounded transmission opportunities from the centralized poller which in most cases is identical to the AP. As accurately assessing the channel capacity is very important for determining whether additional trafc can be accommodated or not, we believe that our way of assessing the channel capacity would be extremely benecial for 802.11e-implementations since the standard denes how to request for such transmission

14

 & %  "   !     $ # #  ! !  

  

 ! !      
SIFS DIFS ACK

time

and

opportunities but does not provide any means to determine the feasibility of such a request.

7 Conclusion and Future Work

In this paper, we introduced the Network Utilization Characteristic for accurately assessing the network capacity and network usage of a wireless local area network. We showed how this value can be accurately computed or estimated on a per-ow basis to assess the actual capacity a ow uses in a wireless network. The computation of the NUC of a ow is possible even in special scenarios such as the use of RTS/CTS and fragmentation. Furthermore, we believe that the proposed NUC can be very helpful in creating IEEE 802.11e implementations. While we present NUC our approach to measure network utilization with particular emphasis on wireless networks, it should be pointed out that this approach can also be used for wired networks. However, its benet is limited as bandwidth and NUC of a ow are not as far apart in a wired network as in a wireless one. Acknowledgement: We would like to thank A.S. Krishnakumar for his helpful suggestions and comments.

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 99108, 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. 535547. [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, submitted. [6] S. Garg and M. Kappes. On the Throughput of 802.11 Networks for VoIP, submitted. 15

[7] IEEE

802.11,

11a,

11b

standard

for

wireless

Local

Area

Networks.

http://standards.ieee.org/getieee802/802.11.html

16