Supporting VoIP Traffic in IEEE 802.11 WLAN with ... - CiteSeerX

Supporting VoIP Traffic in IEEE 802.11 WLAN with Enhanced Medium Access Control (MAC) for Quality of Service







Dongyan Chen , Sachin Garg , Martin Kappes and Kishor S. Trivedi  Center for Advanced Computing and Communications (CACC) Department of Electrical and Computer Engineering Duke University, Durham, NC 27708-0294  Avaya Labs Research 233 Mount Airy Rd., Basking Ridge, NJ 07920

Abstract – With fast deployment of wireless local area networks (WLANs), the ability of WLAN to support real time services with stringent quality of service (QoS) requirements has come into fore. In this paper, we 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 for QoS in the IEEE 802.11e supplements, to support voice over IP (VoIP) applications. The performance of VoIP under EPCF and EDCF is shown through simulations, and the impact of background traffic on the VoIP performance is also evaluated. Our results show that under the EPCF mode the end to end delay of VoIP traffic may be effectively controlled with admission control, and is not sensitive to the best effort traffic offered in contention based operation mode. Index Terms—Wireless local area networks, voice over IP, quality of service

I. I NTRODUCTION Wireless local area networks (WLAN) hold the promise of providing unprecedented mobility, flexibility and scalability. In the last few years wireless networks based on the IEEE 802.11b standard have gained popularity and have been widely deployed in enterprises. IEEE 802.11 covers the media access control (MAC) layer and physical layer specifications for WLANs [1]. The IEEE 802.11 standard specifies two different channel accessing mechanisms, namely, the distributed coordination function (DCF) and point coordination function (PCF). DCF is based on the carrier sense multiple access with collision avoidance (CSMA/CA) channel accessing mechanism, while PCF is based on polling. The default scheme for DCF is a two-way handshaking technique where a positive acknowledgment is transmitted by the destination station upon successful reception of a packet from the sending station. The acknowledgement is needed since the sender cannot listen to its own transmission and therefore cannot determine whether its transmission is successful or not. In the PCF operation mode, stations are polled This work was done while Dongyan Chen was a Summer Intern at Avaya Labs

in turn, and the station with a packet pending for transmission sends out the packet upon being polled. While DCF and PCF mode may provide satisfactory performance in delivering best effor traffic, they lack the support for quality of service requirements posed by real time traffic such as voice over IP (VoIP), which requires  Low end to end delay (normally in the range of  ms to  ms); and  Low delay jitter. These requirements make the DCF scheme an infeasible option to support quality of service for realtime traffic. Furthermore, [5] showed that apart from these limitations, a typical WLAN with 11Mbps bandwidth could only support a very limited VoIP connections in DCF mode. On the other hand, PCF mode, with a centralized controller, pops up as another promising alternative to providing QoS in wireless LAN [6] [8]. However, during our previous studies on carrying VoIP over WLAN in PCF mode [4], we find that the following problems still exist:  When the number of stations in a basic service set (BSS) is large, the polling overhead is high and results in excessive end to end delay  Without service differentiation, VoIP connections still get poor performance under heavy load conditions  The duration of the contention period (CP), in which the system works in DCF mode, is strictly limited by the smallest packet inter-arrival time of the VoIP calls. Moreover, when the number of VoIP calls is large and the VoIP calls are not synchronized, the CP duration may be even smaller and make the co-existence of DCF and PCF mode in such situation virtually impossible. To support LAN applications with QoS requirements, the IEEE 802.11e supplement is currently under development[2]. It introduces the concept of hybrid coordination function (HCF) for the media access control mechanism. HCF is upward compatible with DCF and PCF, and at the same time it provides QoS stations with prioritized and parameterized QoS access to the wireless medium. HCF combines aspects of both the contention-based and the polling-based access methods, while the contention-based channel access mechanism of HCF is called extended DCF (EDCF) and the contention-free chan-

nel access  mechanism of the HCF is called the extended PCF (EPCF). EDCF provides differentiated, distributed access to the wireless medium for  delivery priorities, each corresponding to an individual prioritized output queue. Each output queue contends for a transmission opportunity (TXOP) using an enhanced variant of DCF wherein  The minimum specified idle duration before starting a frame transmission (DIFS for DCF) is different for each specific queue (arbitration IFS, or AIFS);  The value of contention window limits, 

 and    , from which the random backoff is computed, are also different for the individual queues;  Lower priority queues defer to higher priority queues within the same station; and  When a higher priority queue collides with a lower priority queue, the higher priority queue gains the TXOP and the lower priority queue behaves as if an external collision occurred and perform the backoff.  The persistence factor (PF) is used to increase the contention window size after each collision. The following equation is used to compute the new contention window size for queue  :

  !#"$%$&  ('*)&+, !.-0/2135467198:/ The EPCF channel access method uses a QoS-aware point coordinator, called hybrid coordinator (HC). The HC uses the point coordinator’s higher channel access priority to allocate TXOPs to wireless stations to transmit QoS data so that the predefined delivery priority, service rate, delay and jitter requirements can be satisfied. A QoS station may send its TXOP requests (also known as Reservation Request, or RR) to the HC either in a TXOP won by this station in EDCF mode or in a TXOP granted to this station in EPCF mode. Besides these mechanisms, RR may also be sent in controlled contention interval (CCI), where contention occurs only among QoS stations that wish to request new TXOPs. During a TXOP in EPCF mode, the polled station may initiate multiple frame exchange sequences. This gives the EPCF the flexibility to support bursty QoS traffic. Although EDCF is a distributed control mechanism and suitable for wireless ad-hoc networks where an AP does not exist, it cannot provide “hard” QoS guarantees. On the other hand, EPCF inherently provides hard QoS guarantees, but it needs a central controller in the network. In terms of capability of supporting VoIP traffic on the WLAN, we argue that the EPCF channel access mechanism is more suitable than EDCF mechanism due to following reasons:  Most VoIP calls are from the wireless network to the wireline network. Therefore, all the real time traffic from the wireline networks need to be routed through the access point (the “bridge” between the WLAN and the wireline network). In this situation, the AP becomes a heavily

loaded node. We know that priorities are granted to specific traffic classes but not specific nodes. Therefore, in EDCF mode, the VoIP packets may be queued at the AP if it cannot gain TXOPs from the competition with other nodes, and will become a bottleneck in the network;  To support VoIP calls between wireless and wireline networks, an AP is required. In such a situation, the functionality of HC may be performed at the AP, and a centralized controller thus naturally exists. Moreover, the AP may gain high priority to access the channel by piggybacking data packets on the QoS-Poll packets or the QoSAck packets, and thus speeds up dispatching packets from wireline networks Based on above observations, in this paper we are mainly interested in evaluating the capability of the EPCF mode to support VoIP traffic in wireless LAN. In our scenario, we assume that both best effort traffic and the VoIP traffic exist in the network. The best effort traffic is transmitted in the EDCF mode, while the VoIP traffic is transmitted in the EPCF mode. Furthermore, we assume that no silence suppression technique is used in the voice codec, and the VoIP traffic is constant bit rate (CBR) traffic. For CBR VoIP traffic, we are interested in the end to end delay of each VoIP connection, as well as their relationship with the number of best effort connections and the burstiness of the best effort traffic. In addition, We also show simulatin results on the VoIP traffic carried in EDCF mode with best effort traffic, based on similar scenarios. Due to space limitations, our study of the variable bit rate (VBR) VoIP traffic case is not reported in this paper. Some of the interesting topics associated with this situation include the design of a call admission control scheme design, as well as the proper selection of CCI durations to maximize system capacity. This paper is organized as follows: Section II briefly introduces the operation of the EPCF mode of an 802.11e WLAN. In Section IV we evaluate the performance of EPCF under VoIP applications with CBR best effort traffic, and in Section V the performance of EPCF under VoIP applications with VBR best effort traffic is addressed. Section VI shows the simulation results of the performance of EDCF under VoIP traffic with best effort traffic. Finally, Section VII concludes the paper. II. BACKGROUND The 802.11e includes an additional channel access method called HCF, which is only usable in QoS network configuration. The HCF combines two enhanced functions of DCF and PCF, namely, EDCF and EPCF. In EPCF mode, a hybrid coordinator (HC) is required as the major control station to poll each mobile station. The HC may be any station in the network. In an infrastructure network, the access point (AP) normally takes up the responsibility to act as the HC. The winning station in EDCF mode or the polled station in EPCF mode obtain a TXOP to transmit the packets. The channel accessing priority of various frames is controlled by the length of time interval between frames, known

EPCF Mode

EDCF Mode

TXOP SIFS

D1+QoSPoll

PIFS D3+QoSPoll

D2+ack

U2+ack

U1+ack

PIFS

SIFS

III. S IMULATION SETUP A. System description

SIFS

QoS-Null

SIFS

DIFS

Fig. 1. PCF frame transfer

as the Inter-Frame Spaces (IFS). There are six different kinds of IFS: Short IFS (SIFS), Distributed cooperation function IFS (DIFS), Point coordination function IFS (PIFS), Extended IFS (EIFS), and Arbitration IFS (AIFS). SIFS is used by acknowledgement packets to successfully received data or control packets, or subsequent packets to a previously sent data packet due to segmentation; DIFS is used by data packets to defer before contending for the channel; PIFS is used by the HC to take control of the channel and start a CFP; EIFS is used by retransmission of a erroneously transmitted data packet in DCF mode; and AIFS is used by different queues in one QoS station. In the EPCF mode, the HC gains control of the channel after sensing the channel idle for a time period equivalent to PIFS. After grabbing the channel, the HC polls a QoS station on its polling list. Upon receiving a poll, the polled station either respond with an QoS-Null packet, if it has no data to send; or it responds with a QoS-Data+QoS-ACK packet, if it has data to send. The polled station may carry out several packet exchange sequences during one TXOP. At the end of a TXOP, the HC gains control of the channel again, and it either send a QoS-Poll to the next QoS station on its polling list after a PIFS interval, or releases the channel if there are no more stations to be polled. This procedure is shown in Figure 1. QoS stations may send TXOP requests during polled TXOPs or EDCF TXOPs as well as during controlled contention intervals (CCIs). The HC controlled contention (CC) mechanism allows stations to request TXOPs without having to contend with EDCF traffic. These requests may be used to initiate either periodic polled TXOPs for traffic with periodic type, or one-time TXOPs to handle bursty traffic. The CC is particularly useful when there is heavy load on best effort (DCF or EDCF) traffic, which makes it hard for QoS stations to send TXOP requests through EDCF. To begin a CC, the HC sends out a contention control packet, which contains such information as the number of controlled contention transmission opportunity (Nccop) and the duration of each CCOP (Dccop). After PIFS, each QoS station that has a TXOP request will randomly pick up a CCOP from Nccop to send its request packet. If collision occurs, the station then need to perform the same procedure in next CCI.

The system framework is shown in Figure 2. There are four different kinds of nodes in the simulation system:  VoIP stations in wireline network, labeled in Figure 2 as Wireline VoIP1 to Wireline VoIP5. We assume all VoIP traffic will go through the AP to the wireline network 1 .  Access points. The access points act as HC during the EPCF mode to send polling packets to each QoS station 2 . The AP maintains a queue for each incoming traffic from VoIP. Upon polling a specific mobile station, the AP will first determine whether there are any packets to be sent to the polled mobile station. If there is, the AP will send a Data + QoS-Poll packet. Otherwise, the AP will send a QoS-Poll packet.  Hubs. The hubs are used to aggregrate VoIP traffic and forward the packets from VoIP sources to AP.  VoIP mobile stations, labeled as Mobile VoIP1 to Mobile VoIP5 in Figure 2. The VoIP traffic is generated by the VoIP mobile stations. A local queue is maintained by each station for its own generated traffic. Newly arrived packets at the mobile stations are inserted to the local queues. To establish a connection, an RR packet needs to be sent to the AP with traffic type field set as periodic traffic. Depending on the operation mode, this RR packet may be sent out through EDCF or CC. After that, no further RR packet is required, and the AP sends periodic polls directed to each individual VoIP terminal with period as requested by the first RR packet. The reservation requests are served at the AP on a first-come-first-serve (FCFS) basis. Upon being polled, the mobile station will either send out a QoSData + Ack packet or a QoS-Ack packet, depending on whether there is data to send.  Best effort traffic mobile stations, labeled in Figure 2 as Best Effort1 to Best Effort5. Best effort traffic is generated by these stations, which is transmitted in the EDCF mode. Since we are only interested in the performance of the wireless LAN, in our simulation we assume that the VoIP sources in the wireline networks are connected to the AP via point to point links and the link delay is negligible. We also assume that there is no channel outages or channel errors for packet transmission. B. Parameter selection According to the IEEE 802.11 protocol specifications, the parameters for the wireless LAN are shown in Table I. For VoIP traffic, three standard voice codecs are considered in this paper, namely, ITU’s G711 a-Law, G729 and G723.1. G711 generates 80 bytes of payload per 10ms without any compression, G729 generates 10 bytes of compressed audio data per 10ms, and G723.1 further compresses the data so that it


bytes @*A bytes /BDC#E @DBDC#E /FA bytes @DB bytes BHG  s

TJ  U @ I O Q PR5- SIFS -

IV. VO IP TRAFFIC UNDER EPCF

generates 24 bytes data every 30ms. We assume the VoIP is established over real-time transport protocol (RTP), which uses UDP/IP between RTP and link layer protocols. The payload at the MAC layer is shown in Table II. C. System capacity The maximal supportable CBR VoIP connections may be found out by some simple computations. Firstly, to avoid the queue build up at each VoIP station, the TXOP granted to each mobile station should be at least SIFS - PIFS

G711 /B ms =B bytes /S@ bytes  bytes @?B bytes => bytes @DA bytes

WITH

CBR

BEST EFFORT

TRAFFIC

TABLE I

Voice codec Packet inter-arrival time Voice packet length RTP layer overhead UDP layer overhead IP layer overhead MAC layer overhead PHY layer overhead

(1)

and Table III shows the maximum capacity of the network under different voice coding schemes calculated from (1).

PARAMETER SELECTION FOR SIMULATIONS

I,JFK%LMLN @ I O Q PR -

PIFS W

G729 /2B ms /B bytes /2@ bytes  bytes @DB bytes ?> bytes @*A bytes

TABLE II VOICE TRAFFIC PARAMETERS

G723.1 ?B ms @*A bytes /2@ bytes  bytes @DB bytes ?> bytes @*A bytes

In our simulation, the number of best effort traffic sources  is . The interarrival time for the packet generation at each best effort traffic source is exponentially distributed with mean X G  ms, and the packet length is exponentially distributed. For voice traffic, we assume the G711 a-Law codec is used, which generates VoIP packets every /B ms with size =B bytes. Since there is only one class of traffic transmitted in EDCF mode, only / queue is used. We assume Y[Z\67] for best effort traffic I equals ^_Z=67]`-ba.]c)R'ST edf , and upon collision, the backoff window is doubled and g7Z=67] is used. Each VoIP connection is established at a random time between  B BhG @=Ei . To inform the HC of the polling request, the W VoIP station sends a RR packet either through EDCF mode, if the network is in contention period, or through CC mode, if the network is in controlled contention interval. Ink CC lil 'QmHmode, the station randomly picks an interval between j/ and W transmits its RR packet. If a collision occurs, the station then waits for the next CCI to transmit its RR packet. The transmission opportunity (TXOP) time requested by the RR packet equals the time to send one VoIP packet plus the time to send an acknowledgement packet. The requested polling interval is /2B ms, which equals the packet inter-arrival time specified by G711 a-Law codecs. Upon receiving a polling packet (QoSPoll), the station sends out the data packet after a SIFS time, with the NAV value being the remaining TXOP time plus DIFS interval. This is to make sure that HC can take control of the channel after this TXOP ends.  Figure 3 shows the average end to end delay with VoIP connections in the system, with the best effort traffic load varied as

−3

1.6

−3

x 10

3

End to end delay (second)

End to end delay (second)

1.4 1.2 1 0.8 No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps

0.6 0.4

1

2

3 4 Time (second)

Fig. 3. End to end delay with

n

5

6

7

x 10

End to end delay (second)

2.5 2 1.5 No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps

1 0.5 0

2

1.5

1

0

1

2

3 4 Time (second)

Fig. 4. End to end delay with

o%n

5

6

No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps 4

6

8

10 12 14 16 Number of VoIP connections

18

20

Fig. 5. End to end delay with respect to the number of VoIP connections

VoIP connections

−3

3

2.5

0.5

0

x 10

7

VoIP connections

 /S@ kbps and @ Mbps per station. From Figure 3 we can observe

that the impact of best effort traffic load on the VoIP connection end to end delay is significant, with the end to end delay more doubled under heavy best effort traffic load. The reason is that although the AP has higher priority in accessing the channel by a shorter defer time (PIFS), it still needs to wait until the channel is idle. Figure 4 shows the case when the number of VoIP  connections is increased to / . It is interesting to note that, when the number of VoIP connections is increased to represent the heavy VoIP traffic load condition, the best effort packet size does not have obvious impact on the end to end delay. The reason is that when the network is heavily loaded, the AP controls the channel almost all the time and the best effort packets can only be transmitted occasionally. To understand the relation between the the end to end delay perceived by each connection and the number of VoIP connec tions, we vary the number of VoIP connection from to / ,  with best effort traffic load set as B , /S@ kbps and @ Mbps per station, respectively. Figure 5 shows the average delay in this =q confidence interval marked. We observe that case, with p

the end to end delay approaches a “saturation” value when the number of VoIP stations exceeds the network capacity, which is /  in this scenario. Since the AP always gives higher priority to connections established earlier, if a lower priority connection cannot get polled in /2B ms it will get “starved” and never be polled since another poll request will be generated by a higher priority connection. In this sense, RR requests that arrive after the system has reached its maximal capacity are denied. Also from Figure 5 we observe that even under heavy VoIP traffic load, the average end to end delay still remains below  ms and satisfies the QoS specification for VoIP. Figure 5 also confirms our observation from Figure 3 and Figure 4 that the impact of best effort load is less significant when the number of VoIP connections is large. In fact, we can see from Figure 5 that when the VoIP connection number exceeds /2B , the end to end delay is almost the same for the  /2@ kbps and @?r bps best effort load case. When the VoIP con nection number exceeds / , the end to end delay for the no best effort case approaches that of the with best effort case. V. VO IP TRAFFIC UNDER EPCF

WITH TRAFFIC

VBR

BEST EFFORT

To evaluate the transportation of VoIP under bursty best effort traffic, we assume the best effort traffic is an ON/OFF process  with mean ON state time being B?B ms and mean OFF state time  being B?B ms. Since Weibull distribution represents a certain degree of burstiness in the traffic by proper choice of parameters [3] [7], we assume the ON state time and the OFF state time follow Weibull distribution. The probability distribution function of Weibull distribution is

4ts2u U:vwxN 6y$ v 1 N / 8z={#| S}%~=R€ W

with its mean given by

gƒ$Ru1 N…„†ˆ‡ $ † / 1 G

 v "‚B

−3

3

0.035

x 10

End to end delay (second)

End to end delay (second)

0.03

2.5

2

1.5

0.5

4

6

8 10 12 14 16 Number of VoIP connections

18

0.02 0.015 0.01 0.005

No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps

1

No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps

0.025

0

0

2

20

4 6 Number of VoIP connections

8

10

Fig. 7. Uplink delay for VoIP in EDCF mode with CBR best effort traffic

‰7Šf‹2Œ n

ŽŠ‹2Œ ‘

Fig. 6. End to end delay of VoIP connections under bursty best effort traffic and ) (Weibull distributed with

P

VI. VO IP TRAFFIC UNDER EDCF

WITH

CBR

BEST EFFORT

TRAFFIC

In this section we evaluate the performance of EDCF mode in support of VoIP traffic. To establish higher priority for VoIP traffic, the YˆZ=67] for VoIP traffic is set equal to ^ƒZ=67] , and the Y[Z\67] for best effort traffic is ^ƒZ\67]7-˜a™]•)R'ST I edf . Upon collision, contention window (CW) for each traffic class follows

 ?šœ› N $!  %K LjO 0 - /215f46“8:/

where 46 is the persistence factor. For VoIP traffic we choose 46 N /=G  while for best effort we choose 46 N @ , as is generated for CW values by DCF. Follwing the terms used in cellular networks, we define the link from the AP to the mobile station as downlink and the link from the mobile station to the AP as uplink. While the end to end delay for the uplink and downlink is the same for EPCF mode, there is a significant difference for the EDCF case since the AP is heavily loaded with traffic from wireline network side and it needs to contend the channel with the other mobile stations. This will introduce a larger downlink delay to each VoIP connection. Such a phenomena is illustrated in Figure 7, which shows the uplink delay of VoIP in EDCF mode, and Figure 7, which shows the downlink delay. We can see from these two figures that while the uplink delay could remain comparatively

No best effort traffic Best effort traffic load = 512Kbps Best effort traffic load = 2Mbps

0.6 End to end delay (second)

‡ v N“’•” 

– T {—  { +?T . † N where $ 1 BhG >  and „ N BHG ?>?> for Figure 6 shows the result with the bursty best effort traffic. It is interesting to note that while best effort traffic still introduces additional end to end delays to VoIP traffic, the amount of increase in the delay is not sensitive to the average best effort traffic load. This might be explained as that under bursty mode, both the light traffic (corresponding  to the /S@ Kbps load per station case) and heavy traffic (corresponding to the @ Mbps load per station case) will both generate heavy traffic during ON period and thus they exhibit the same impact on the VoIP connections.

0.7

0.5 0.4 0.3 0.2 0.1 0

0

2

4 6 Number of VoIP connections

8

10

Fig. 8. Downlink delay for VoIP in EDCF mode with CBR best effort traffic

small (under /B ms) with the VoIP connection number increased X to , the downlink delay goes up abruptly when the VoIP connection number exceeds A with best effort traffic, or > without best effort traffic. This indicates that the maximal system capacity to support VoIP traffic is > in EDCF mode, and the existence of best effort traffic may introduce a significant impact on system performance and capacity. VII. C ONCLUSION In this paper, we have evaluated the performance of enhanced MAC protocols for QoS in IEEE 802.11 WLAN, in carrying VoIP applications. Our results show that in the scenario where VoIP calls are made between wireline and wireless networks, the enhanced PCF operation mode provides low end to end delays for voice calls, and its performance is not sensitive to background best effort traffic. Moreover, by adopting a firstcome-first-serve policy for QoS VoIP connections, the system is stable even under heavy load conditions and still meet the QoS requirements posed by VoIP connections. Our future work in this field will be in evaluating the performance of EPCF mode in carrying VBR VoIP traffic, as well as call admission control policy design and analysis of optimal

controlled ž contention intervals in assuring QoS for VoIP applications. R EFERENCES [1] IEEE Std 802.11, IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer Specifications, November 1997. [2] IEEE Draft Std 802.11e, Medium Access Control (MAC) Enhancements for Quality of Service (QoS), D2.0a, November 2001. [3] G. Anastasi and L. Lenzini. QoS provided by the IEEE 802.11 wireless LAN to advanced data applications: a simulation analysis. Wireless Networks, (6):99–108, 2000. [4] D.-Y. Chen, S. Garg, M. Kappes, and K. S. Trivedi. Supporting VBR VoIP traffic with IEEE 802.11 WLAN in PCF mode. In Proceedings of OPNETWork 2002, Washing D.C., August 2002. [5] S. Garg and M. Kappes. On the throughput of 802.11b networks for VoIP. In submitted for publication. [6] M. Veeraraghavan, N. Cocker, and T. Moors. Support of voice services in IEEE 802.11 wireless LANs. In Proceedings of INFOCOM’01, 2001. [7] W. Willinger, M. S. Taqqu, R. Sherman, and D. V. Wilson. Self-similarity through high variability statistical analysis of Ethernet LAN traffic at the source level. In Proceedings of ACM SIGCOMM’95, pages 100–113, 1995. [8] J.-Y. Yeh and C. Chen. Support of multimedia services with the IEEE 802.11 MAC protocol. In Proceedings of ICC’02, New York, April 2002.