IEEE 802.11e無線網路環境下的VoIP傳輸品質控管

全文

(1)Design of QoS and Admission Control for VoIP Services over IEEE802.11e WLANs Student: Pei-Yeh Wu Advisor: Prof. Yu-Chee Tseng. A Dissertation Submitted to the Department of Computer Science and Information Engineering College of Electrical Engineering and Computer Science National Chiao-Tung University in partial Fulfillment of the Requirements for the Degree of Master in Computer Science and Information Engineering Hsinchu, Taiwan July 2005.

(2) IEEE 802.11e 無線網路環境下的 VoIP 傳輸品質控管. 學生：吳佩曄. 指導教授：曾煜棋教授. 國立交通大學資訊工程學系﹙研究所﹚碩士班. 摘. 要. 在無線網路環境下來支援網路電話的運行是近年來崛起的新服務。要來支援這樣的服務，SIP 和 IEEE802.11e 是兩個很重要且有遠景的協定。在這個碩論裡面，我們提出了一個整合 SIP 和 802.11e 的架構來做網路資源管理，以達到網路電話在無線網路下的品質要求。此外，我們也提出了一些在 IEEE802.11e 網路擷取層上的改善方法，期許可以讓無線網路環境下的網路電話服務可以運行的更加順暢。. i.

(3) Design of QoS and Admission Control for VoIP Services over IEEE 802.11e WLANs Student: Pei-Yeh Wu. Advisors: Prof. Yu-Chee Tseng. Institute of Computer Science and Information Engineering National Chiao-Tung University. ABSTRACT. Supporting telephone services using wireless LAN as the access network is an emerging service. The SIP and IEEE 802.11e are perhaps the two most promising protocols to support such services. In this paper, we show how to integrate SIP and 802.11e to conduct call admission control and resource reservation to support VoIP’s QoS in IEEE 802.11e WLANs. Besides, we also suggest some adjustments and MAC enhancements to 802.11e to facilitate VoIP traffics over WLANs.. Keywords: Call admission control, IEEE 802.11e, quality of service (QoS), voice over IP (VoIP), wireless network.. ii.

(4) Acknowledgments My advisor, prof. Yu-Chee Tseng, is the first one I would like to express my gratitude to. With the wonderful research conditions he provided and his attentive instructions, I came to discover the pleasure of research. I am also grateful to my senior, Shiang-Rung Ye. Without his help and suggestions, I would not be able to have this thesis done. Finally, I would like to thank all HSCC members for their generous advices. Discussing with them benefited me in many ways. Pei-Yeh at CSIE, NCTU.. iii.

(5) Contents 摘要. i. Abstract. ii. Acknowledgments. iii. Contents. iv. List of Figures. v. List of Tables. vii. 1 Introduction. 1. 2 Preliminaries. 4. 2.1. 802.11e MAC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2.2. SIP and SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 3 The Proposed QoS Architecture for VoIP Services. 10. 3.1. Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. 3.2. Resource Readjustment During Transmission . . . . . . . . . . . . . . 15. 4 MAC Enhancements for VoIP Traffics. 17. 5 Simulation Results and Discussions. 19. 6 Conclusions. 29. Bibliography. 30. Curriculum Vita. 31 iv.

(6) List of Figures 2.1. The mappings of 802.1D priorities to IEEE 802.11e ACs. . . . . . . .. 5. 2.2. Management of access categories in EDCA. . . . . . . . . . . . . . . .. 6. 2.3. Structure of the IEEE 802.11e EDCA Parameter Set information element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 2.4. TSPEC information element of IEEE 802.11e. . . . . . . . . . . . . .. 7. 2.5. A example of SIP call setup and tear-down. . . . . . . . . . . . . . .. 8. 2.6. An example of SIP with SDP message bodies: (a)INVITE siganl and (b)OK signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.1. 9. The proposed QoS architecture for SIP call establishment in 802.11e networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. 3.2. The Packet Size Table, which gives the packet sizes (in bytes) when different codecs and packetization intervals are used.. . . . . . . . . . 12. 5.1. Scenario A: The number of calls as time goes on. . . . . . . . . . . . 20. 5.2. Scenario A: Total goodput of the WLANs either the CAC mechanism is applied. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21. 5.3. Scenario A: Throughput of background traffic in the WLANs either the CAC mechanism is applied. . . . . . . . . . . . . . . . . . . . . . 21. 5.4. Scenario A: Average collisions number per-QSTA per-second either the CAC mechanism is applied. . . . . . . . . . . . . . . . . . . . . . 22. 5.5. movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. 5.6. Scenario B: Average goodput per-QSTA per-second when WLAN has 5, 10, 15, 17 VoIP calls. AC in the figure presents the goodput under the condition which all QSTAs is static; AC M means the non-AP QSTA will move in the way we defined; AC ME shows the goodput improvement with our enhancement under the mobile environment . . 24. v.

(7) 5.7. Scenario B: Average collisions when WLAN has 5, 10, 15, 17 VoIP calls. The figure shows the condition of collision within 100 seconds within 100 seconds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24. 5.8. The calculating number of VoIP calls an QAP can support with different conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. 5.9. The number of VoIP calls an QAP can support when AC VO queues size is 50 frames and dropping rate is smaller than 0.02. . . . . . . . . 25. 5.10 Scenario D: In this figure, AC R means there is a mechanism of redirecting packet to AC BE queue except original admission control. AC M R is the condition that using the redirect mechanism when mobility function is on. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.11 Scenario D: This figure shows the goodput variation within 100 seconds when there are 17 VoIP calls. . . . . . . . . . . . . . . . . . . . 27 5.12 Scenario E: The average goodput enhancement per-QSTA per-second when we enhance the QAP to profit the downlink traffic. . . . . . . . 27 5.13 Scenario E: The average collision numbers per-QSTA per-second either of enhancing the QAP to profit the downlink traffic or not. . . . 28. vi.

(8) List of Tables. vii.

(9) Chapter 1 Introduction Recently, we have seen two major trends in the area of communications. First, IEEE 802.11 WLANs have been widely deployed in the world. Second, due to the growth of Internet bandwidth, real-time audio and video applications have become more mature and popular. The combined effect has made VoIP (voice over IP) over WLANs possible. For example, to support VoIP, new products have appeared, such as Wi-Fi phones and dual-mode cellular-WiFi phones (e.g., Cisco Wireless IP Phone 7920 [1] and Motorola MPx [2]). The above observation has raised an interesting issue: how do WLANs support QoS (Quality of Service) and CAC (Call Admission Control) for VoIP traffics. The IEEE 802.11 Task Group E (802.11e) [3] has been formed to expand the current 802.11 MAC protocol to support applications with QoS requirements. In addition, the Session Initiation Protocol (SIP) [15, 5] has been widely accepted as the signaling protocol for VoIP to handle the setup, modification, and teardown of VoIP sessions. In this work, we consider the cross-layer protocol design problem to facilitate VoIP traffics over IEEE 802.11e WLANs. We show how 802.11e can cooperate with VoIP SIP signaling to conduct QoS and CAC over the wireless channel. We also propose enhancements to 802.11e MAC part to improve its performance in delivering VoIP traffics. Several prior works have focused on improving VoIP traffics in WLAN environments. Reference [6] claims that admission control is critical to protect VoIP traffics because resources in a WLAN cell is limited. A CUE (Channel Utilization Estimation) is proposed to determine whether to accept a new call. Alternatively, giving priority to VoIP traffics helps improving performance too [9]. References [4, 17]. 1.

(10) point out that the bottleneck is at the access point (i.e., down link traffic). Hence, a BC-PQ (Backoff Control and Priority Queue) mechanism [4] is proposed to give priority to voice traffics over data traffics and assign zero backoff time to voice packets in access points. On the other hand, it is proposed to separate real-time and non-real-time packets into two queues in [17], and an AP always processes the realtime queue first whenever it is not empty. The number of concurrent VoIP sessions that can be supported in a WLAN is evaluated in [7, 10]. It is reported that besides the bandwidth limitation of the physical layer, the codec, packetizaion interval, and delay budget may all influence the number of VoIP sessions that can be supported. It is further pointed out that the selection of packetization interval has more impact than the selection of codec. On the standardization track, the IEEE 802.11 working group R (802.11r) is currently developing fast roaming mechanisms. Reference [11] proposes a structure to integrate Mobile IP with SIP to assist VoIP mobility, while [14] suggests using ad hoc-assisted handoff to meet the Qos requirement of VoIP during handover. The IEEE 802.11e aims at enhancing its MAC mechanism to support QoS. Several works [8, 12, 13, 16] have studied using 802.11e to improve multimedia transmission under WLAN. QoS schedulers based on HCCA of IEEE 802.11e are proposed in [8, 12]. Some works discuss how to ameliorate EDCA in IEEE 802.11e to facilitate multimedia transmission. Reference [13] extends the basic EDCA by using an adaptive fast backoff mechanism along with a window doubling mechanism at busy period. In [16], it is suggested that in EDCA each mobile station must conduct admission control on real-time traffic streams to protect existing real-time sessions, and that AP must adjust lower-priority Access Categories’ contention windows, Arbitration Inter-frame Spacing (AIFS), and so forth, to protect real-time sessions from being collided by those that do not require admission control. In this paper, we show how to support VoIP services over WLAN environments. Existing works are not designed for this purpose. In particular, we show how to integrate IEEE 802.11e with SIP to conduct call admission control over WLAN environments and support QoS for VoIP calls. We believe that cross-layer design is essential for maintaining the QoS of VoIP services. Moreover, we also show how to increase the number of VoIP sessions being supported under an AP with compromising QoS and how to improve the MAC mechanism of IEEE 802.11e to facilitate the transmission of VoIP traffics.. 2.

(11) The rest of this paper is organized as follows. We will give some preliminaries in Section 2. The proposed QoS architecture for VoIP service will be introduced in Section 3. Section 4 presents several MAC enhancements of IEEE 802.11e for VoIP services and Section 5 gives some simulation results and discussions. Finally, Section 6 draws our conclusions.. 3.

(12) Chapter 2 Preliminaries 2.1. 802.11e MAC Protocol. The current IEEE 802.11 MAC has no means of differentiating TSs (traffic streams) or sources. All packets are treated equally in both DCF and PCF. As a result, no consideration can be made for the service requirements of traffics. The IEEE 802.11 Working Group E has proposed a HCF (Hybrid Coordination Function) for both ad-hoc and infrastructure modes. Several enhancements are introduced in 802.11e. First, a concept called TXOP (Transmission Opportunity) is introduced, which is a period of time during which a QSTA (a station that supports 802.11e) can exclusively use the wireless medium. A TXOP is defined by a starting time and a maximum duration and it can be obtained by contention or by assignment from the HC (Hybrid Coordinator). Second, IEEE 802.11e supports traffic differentiation by giving traffic streams priorities. Third, it allows a TS to specify its traffic characteristic. HCF supports two access methods, a contention-based mechanism called Enhanced Distributed Channel Access (EDCA) and a contention-free mechanism called HCF Controlled Channel Access (HCCA). Since HCCA is enhanced from PCF and PCF is seldom implemented, we only discuss EDCA in the following. EDCA of IEEE 802.11e To differentiate services, IEEE 802.11e adopts the eight user priorities in 802.1D and maps then to four Access Categories (ACs) (refer to Fig. 2.1). EDCA supports these ACs by four separated queues in both QAP (an AP that supports 802.11e) and QSTA, as illustrated in Fig. 2.2. Each queue operates as an independent entity and conducts backoff as in the original IEEE 802.11 DCF. The ith AC, i=0..3, has. 4.

(13) Figure 2.1: The mappings of 802.1D priorities to IEEE 802.11e ACs. its own arbitration inter-frame space (AIF S[i]), initial window size (CW min[i]), and maximum contention window size (CW max[i]). If multiple queues finish their backoff simultaneously, the virtual collision handler will choose the AC with the highest priority to send and the lower priority AC(s) will back off as experiencing an external collision. The EDCA Parameter Set information element (Fig. 2.3) can be sent in beacon frames. It also contains the TXOP limit of each AC, which bounds the amount of burst transmission of a QSTA after it successfully contends the medium. If TXOP limit equals zero, a QSTA can transmit only one packet each time it gains the TXOP. Admission Control in EDCA A QAP uses the ACM (admission control mandatory) subfield advertised in EDCA Parameter Set to indicate whether admission control is required for each AC. A QSTA can send an ADDTS (add traffic stream) request to the QAP to request adding a new traffic stream by specifying its direction (uplink, downlink, bidirectional, or direct) and providing a TSPEC (traffic specification) information element as shown in Fig. 2.4. Some important fields in TSPEC are discussed below: • Minimum Data Rate: the lowest data rate (in bits per second) to transport MSDUs. • Mean Data Rate: the average data rate (in bits per second) to transport MSDUs. • Peak Data Rate: the maximum allowable data rate (in bits per second) to transport MSDUs. 5.

(14) Multiplexing of Access Categories. AC_VO. AC_VI. AC_BE. AC_BK. CW[3] AIFS[3]. CW[2] AIFS[2]. CW[0] AIFS[0]. CW[1] AIFS[1]. Virtual Collision Handler. Figure 2.2: Management of access categories in EDCA.. Figure 2.3: Structure of the IEEE 802.11e EDCA Parameter Set information element.. 6.

(15) Figure 2.4: TSPEC information element of IEEE 802.11e. • Minimum PHY Rate: the desired minimum physical rate for this traffic stream. • Medium Time: the amount of time admitted to a stream to access the medium. This field is not used in the ADDTS request frame, but will be set by the HC in the ADDTS response frame. On receiving an ADDTS request, the QAP may decide to accept or reject it. In the former case, the QAP will calculate a MT (Medium Time) for this traffic stream per beacon interval and reply an ADDTS response containing this information; otherwise, an ADDTS response including rejection information is replied. For QAP and each QSTA, they keep the total MT and consumed MT of each AC. Only when the former is lager than the latter, can packets in the corresponding AC be transmitted. After each beacon interval, the consumed MT will be reset to zero. The QAP can identify a traffic stream by its TSID and direction. This information is available in the TS info field in TSPEC. In this paper, we will use bidirectional reservation for VoIP sessions.. 2.2. SIP and SDP. SIP is a signaling protocol, which is considered as an attractive alternative to H.323 to support VoIP. SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions. It often cooperates with other protocols, such as SDP (Session Description Protocol)1 to describe session characteristics and 1. SDP is specified in RFC 2327. It does not provide a means for transporting or advertising.. RFC 3264 describes how SDP co-works with SIP.. 7.

(16) C aller. C allee. Susan@station1.nctu.edu.tw. Mar y@station2.nthu.edu.tw IN V IT E. R inging. OK ACK. C om m unication. BYE. OK. Figure 2.5: A example of SIP call setup and tear-down. RTP (Real-time Transport Protocol)2 to send traffic after call setup. SIP is designed to keep signaling as simple as possible. Fig. 2.5 shows one example of call establishment. When a caller wants to make a VoIP connection with a callee, it sends an INVITE including the codecs that the caller supports in a SDP message body. Fig. 2.6(a) is an example, with G.726 (2), G.723 (4), and G.728 (15) as the selections (numbers in parentheses are payload types) and 123 the receive port. If the callee decides to accept the request, it replies a Ringing and an OK signals to the caller. The OK signal will contain the callee’s choice of codec. In Fig. 2.6(b), the callee chooses G.728 (15), using the receive port of 888. A port number of 0 indicates a rejection.. 2. RTP is often accompanied with RTCP (RTP Control Protocol) to provide transport services. to support real-time applications.. 8.

(17) (a). (b). Figure 2.6: An example of SIP with SDP message bodies: (a)INVITE siganl and (b)OK signal.. 9.

(18) Chapter 3 The Proposed QoS Architecture for VoIP Services We consider an IEEE 802.11e wireless network operating in the infrastructure mode to support VoIP applications. We adopt SIP for call setup and management. We also assume that a VoIP session can dynamically adjust its packetization interval (PI ) even during communication, where PI represents how frequently voice data should be encapsulated into packets. Our purpose is to guarantee high QoS for admitted VoIP sessions when the network load is not heavy, and to support as many VoIP connections with acceptable QoS as possible when the network load is heavy. RFC 3312 (Integration of Resource Management and SIP) discusses how QoS can be made a precondition for sessions initiated by SIP. These preconditions require that participants reserve network resources before continuing. Inspired by this, we propose an architecture for IEEE 802.11e to incorporate with SIP to conduct resource reservation and admission control.. 3.1. Call Establishment. Fig. 3.1 shows the proposed QoS architecture after integrating SIP with IEEE 802.11e. When a caller under QAP1 wants to establish a VoIP connection with a callee at QAP2, it can send an INVITE signal with a SDP message containing necessary codec information to the callee. QAP1 and QAP2, on receiving this INVITE signal (refer to boxes A and B in Fig. 3.1), will do pre-resource reservation and possibly filter out some codecs that they cannot support due to bandwidth. 10.

(19) Caller. QAP2. QAP1. Callee. INVITE. A. INVITE. B. INVITE ADDTS request. D Ringing OK. ADDTS response. Ringing. Ringing. OK. OK. C. ADDTS request. E. ADDTS response. ACK. F ACK. ACK. Communication. Figure 3.1: The proposed QoS architecture for SIP call establishment in 802.11e networks. constraints. When the callee receives this INVITE signal (refer to boxes C and D), it will exchange 802.11e ADDTS request and response with QAP2. These steps can prevent ghost rings1 . After exchanging ADDTS messages, the callee can send Ringing and OK signals to the caller. The OK signal will contain the codec being selected by the callee. After receiving the OK signal, the caller will exchange ADDTS request and response with QAP1 (refer to boxes E and F). If these steps successfully go through, an ACK signal will be replied to the callee. In the following, we will explain the detail actions to be taken in boxes A, B, C, D, E, and F. A. Pre-resource Reservation at the Caller A QAP has to broadcast the PHY rates that it can support in its beacon frames. When a QSTA is associated with a QAP, it also registers with the QAP its supported rates. In IEEE 802.11e, a QSTA can specify its minimum PHY rate when adding a new traffic stream. When the QSTA can transmit/receive at this rate, the requested QoS should be guaranteed; otherwise, the requested QoS is not necessarily guaranteed. To conduct pre-resource reservation, we propose that each QAP keeps a Packet Size Table (PST) as in Fig. 3.2, which contains the packet sizes when different codecs and packetization intervals (PI) are used. For example, in G.726 with a sampling rate of 32 kbps, if a packetization interval of 20 ms is used, then 1. A ghost happens when a user can not communicate with the other side as he/she picks up a. ringing phone. The shortage of bandwidth is often a reason for ghost rings in VoIP applications.. 11.

(20) Figure 3.2: The Packet Size Table, which gives the packet sizes (in bytes) when different codecs and packetization intervals are used. each packet is of size 154 bytes (which contains 80 bytes of voice payload, 40 bytes of IPv4/UDP/RTP/error-checking overhead, and 34 bytes of MAC/error-checking overhead). The payload sizes generated by different codecs can be inferred from [5]. Note that the calculation does not include the PLCP preamble and header, which are 24 bytes and must be sent at the lowest rate of 1 Mbps. Therefore, given a codec and its packetization information, QAP1 can compute a medium time (MT) that should be reserved for the traffic stream per beacon interval (BI): M T = (total time needed per BI) = (time to send one packet) × (no. packets per BI) ×(surplus bandwidth allowance) = [(PLCP preamble and header) + payload + SIF S + ACK] ×(BI/PI) × (surplus bandwidth allowance) = [(packet size)/(min PHY rate) + 2 × PLCP/Mbps +(ACK/min PHY rate) + SIF S] ×(BI/P I) × (surplus bandwidth allowance). (3.1). According to 802.11, SIFS is 10 µs, ACK packet is 14 bytes, and PLCP preamble and header are 24 bytes. The surplus bandwidth allowance is a value slightly larger than 1 to take into account the excess time for possible contentions and retransmissions (in statistical sense). In this work, we assume its value to be 1.1. For example, when BI is 1 sec and min PHY rate is 11 Mbps, if we use G.726 with 32 kbps and PI of 20 msec, then MT = [154/11(bytes/M bps) + 2 ∗ 24(bytes/M bps) + 14/11(bytes/M bps) + 10µs] ∗ (1000/20) ∗ 1.1 = 28.39 ms. 12.

(21) For each codec in the INVITE signal, if its MT exceeds the remaining MT of QAP1, we will remove the codec from the codec list. In case that the remaining resource in QAP1 does not allow it to support any codec, QAP1 can drop the INVITE silently or reply a SIP response to the caller with a status code of 480, which means “temporarily not available”. Also note that since voice communications are bi-directional, the AP should reserve 2 × M Tmax , where M Tmax is the maximum time required by all codecs in the list. B. Pre-resource Reservation at the Callee The calculation of medium time at the callee when receiving the INVITE signal is similar to the above discussion. QAP2 will also filter out those codecs that it cannot support from the INVITE siganl and reserve the maximum required bandwidth. The INVITE signal will then be forwarded to the callee if at least one codec can be supported. C. ADDTS Request by the Callee After deciding the codec, the callee can send a bidirectional ADDTS request to QAP2 by including a TSPEC element. We suggest to convey VoIP service requirements with the following fields in TSPEC: • Minimum Data Rate = the acceptable longest packetization interval of the corresponding codec. • Mean Data Rate = the packetization interval selected by the callee. • Maximum Data Rate = the acceptable shortest packetization interval. • Medium Time = the codec selected by the callee. With these information, QAP2 can do CAC as described in the following part D. D. Call Admission Control in QAP2 According to the callee’s ADDTS request and the Packet Size Table, QAP2 can compute the required medium time following the equation in step A. Note that with a bidirectional request, the same medium time should be applied to both uplink and downlink directions. In order to conduct call admission control, each QAP should keep the following variables: • TXOPBudget[ACi ]: The remaining bandwidth that can be allocated by ACi ,i=0..3. 13.

(22) • TxAdDn[ACi ][TSID]: The admitted medium time for stream TSID of ACi in the downlink direction. • TxAdUp[ACi ][TSID]: The admitted medium time for stream TSID of ACi in the uplink direction. • TxAdDn[ACi ]: This value is set to. P. ∀T SID TxAdDn[ACi ][TSID],. to record the. overall resource allocated to ACi in the downlink direction. • TxUsedDn[ACi ]: The summation of used medium time of all downlink streams of ACi . Initially, TXOPBudget[ACi ] contains all the bandwidth (in terms of medium time) that is reserved for ACi . Whenever a new stream is added, the corresponding resource is subtract from TXOPBudget[ACi ], and the resource is assigned to TxAdDn[ACi ][TSID] and/or TxAdUp[ACi ][TSID]. Also, each QSTA should keep the following variables: • TxAdUp[ACi ][TSID]: The admitted medium time for stream TSID of ACi in the uplink direction in this STA per BI. • TxAdUp[ACi ]: This value is set to. P. ∀T SID TxAdUp[ACi ][TSID],. to record the. overall resource allocated to ACi of this STA in the uplink direction. • TxUsedUp[ACi ]: The summation of used medium time of all uplink streams of ACi . Resource reservation at QAP2 is done as follows. First, we compute the value of TXOPBudget[ACi ] − 2∗MT. If the value is non-negative, there is sufficient resource to support this call and we can set TXOPBudget[ACi ] = TXOPBudget[ACi ] − 2∗MT; TxAdDn[ACi ][TSID] = MT; TxAdUp[ACi ][TSID] = MT; TxAdDn[ACi ] = TxAdDn[ACi ] + TxAdDn[ACi ][TSID] ; Where MT is computed form Eq. (3.1) based on the information of codec, PI, min PHY rate, etc., provided by the TSPEC. If there is no sufficient resource, the QAP can choose the next larger PI (if possible), recompute a new MT, and repeat the above testing, until a satisfactory PI is found. Then QAP2 will reply an ADDTS 14.

(23) response to the callee with the Mean Data Rate = PI and Medium Time = MT in the TSPEC. If there is no sufficient resource, then an ADDTS response is replied with Medium Time = 0. At the callee’s side, if an ADDTS response with a positive Medium Time is received, then the QSTA sets its TxAdUp[ACi ][TSID]=Medium Time and retrieves the PI in the Mean Data Rate field and passes it to the upper layer VoIP application program. Otherwise, the call is considered rejected. In both cases, the callee should reply a response signal with the proper status code to the caller. E. ADDTS Request by the Caller When the caller receives the OK signal with codec information from the callee, it will send an ADDTS request to QAP1. The operations are similar to step C. F. Call Admission Control in QAP1 The action is similar to step D. If the caller receives a successful ADDTS response, it will send an ACK signal to the callee. Then, the voice communication can be started. Because of the pre-resource reservation in steps A and B, a lot of potential ghost rings can be avoided. Also, voice quality can be guaranteed because of the CAC in steps D and F. Finally, we remark that although we assume that both the caller and the callee are under WLANs, the above procedure should work well if any side is not under a WLAN.. 3.2. Resource Readjustment During Transmission. The above steps are for the setup of new calls. However, during transmissions, a stream may dynamically change its bandwidth requirement. In this subsection, we will introduce the steps to be taken alleviate such problems. 1. Estimation of Downlink PI by QAPs We note that the PI selected by a codec is not conveyed via SIP signals to the codec at the other side. Therefore, although the resource reservation mentioned above in the uplink direction (from QSTA to QAP) is accurate, the MT reserved for the downlink direction is only an approximation. To solve this problem for each stream TSID, we require a QAP to observe packets from the other side for several beacon intervals and estimate the actual PI being used. After estimating the actual. 15.

(24) PI, the QAP should calculate the MT according to Eq. (3.1) for this stream and then update TxAdDn[AC VO][TSID] and TxAdDn[AC VO]. 2. Adjustment for PHY Rate Change at QSTAs When a traffic stream finds that its admitted medium time is not enough to send all of its packets because its physical rate drops below its specified min PHY rate, we suggest that the QSTA can send an update ADDTS request to its QAP with the min PHY rate field equal to its current PHY rate or below. The operations are similar to the above steps C and D. The QAP may respond in two ways: to allocate more medium time for the stream if it still has more resource available, or to suggest a longer PI to reduce the required medium time of the corresponding traffic stream. If the request succeeds, a new medium time will be replied; otherwise, the QAP will reply with the stream’s original medium time. In the latter case, the call may suffer from lower quality. 3. Mechanisms to Support More VoIP Sessions When a WLAN is very congested or when there are more new VoIP calls intending to join the WLAN, we may ask current calls to reduce their resource consumption. On finding such a situation, a QAP can send a beacon frame by carrying such a notification to its QSTAs. A QSTA may respond in two ways : • The QSTA may change the PI of one of its streams by notifying the corresponding codec as well as sending a new ADDTS request to the QAP with a longer PI. The QAP should grant the ADDTS request. • The QSTA may decide to ask one of its streams to change to a lighter-load codec. This can be achieved by the RE-INVITE or UPDATE signal of SIP.. 16.

(25) Chapter 4 MAC Enhancements for VoIP Traffics In this section, we discuss several enhancements to improve the performance of 802.11 medium access to support VoIP traffics. • First, some control mechanisms are needed to achieve the CAC mentioned above. Only admitted VoIP sessions can drop packets to the AC VO queue. Besides, for each ACi that requires admission control, we must keep the medium time that it can use in TxAdUp[ACi ] and TxAdDn[ACi ] and the amounts of time that have been used in TxUsedUp[ACi ] and TxUsedDn[ACi ] in current beacon interval. This bookkeeping work must be done for every data frame being transmitted. Only when TxUsedDn[ACi ] < TxAdDn[ACi ] (resp., QAPs or TxUsedUp[ACi ] < TxAdUp[ACi ]) can the corresponding access category ACi contend for the medium in the QAP (resp., QSTA). Also, the value of TxUsed[ACi ] in each station should be reset to zero at the end of each BI. • Second, to avoid the sudden congestion of the network, whenever a packet is generated by an admitted TS, the system can estimate whether the remaining medium time of the AC VO queue (i.e., TxAdDn[AC VO] − TxUsedDn[AC VO] − (the amount of data buffered in the AC VO queue) for QAP, or TxAdUp[AC VO] − TxUsedUp[AC VO] − (the amount of data buffered in the AC VO queue) for QSTA) is enough to send this packet or not. If so, this frame will be dropped to the AC VO queue as normal; otherwise, this packet will be placed. 17.

(26) to any AC that doesn’t need admission control. Intuitively, this is to transfer the burst arrival of VoIP packets that can not be delivered in the current beacon interval to other best-effort queues, hoping to deliver them by their due dates. This mechanism may help improve the performance of VoIP traffics when the physical rate decreases or when there is a sudden increase of the collision probability in the network. • Third, when a station finds that its dropping rate is higher than a threshold, it can check the receive signal strength of its current QAP. If the signal quality is poor, it may consider switching to a new QAP of better signal quality. If the signal is good, then the cause might be an unexpected high contention from other ACi s. In this case, the STA may ask the QAP to increase the CW and AIFS of other access categories. Afterward, when the network is not so highly congested, the QAP may decide to ask other STAs to return to their original CW and AIFS. This is similar to what is suggested in [16]. • Finally, we observe that in many cases the performance bottleneck of the network is at the QAP. This is because the QAP is in charge of delivering packets for multiple streams. So, a higher priority should be given to QAP. In our design, we will facilitate its transmission as follows: whenever the QAP receives VoIP packets from a station i, it is allowed to immediately allocate a TXOP to transmit packets of station i in the AC VO queue after a SIFS. In this way, the QAP will have more change to transmit than QSTAs.. 18.

(27) Chapter 5 Simulation Results and Discussions An event-driven simulator is developed to evaluate the performance of the proposed CAC and MAC enhancements. Unless otherwise stated, the following assumptions are made in our simulation. (1)We set TXOP limit to be zero for four ACs, which means that a QSTA can only transmit one packet each successful contention. (2)We assume an error-free IEEE 802.11b/e environment in which there are one QAP and several QSTAs. No RTS/CTS is used. (3)The beacon interval(BI) is set to 500ms. (4)Each QSTA, except the one to generating background traffic, has a VoIP session(AC VO) using G.726 as the codec with PI equal to 20ms. (5)We assume there are two static QSTAs generating background traffic(AC BK) by poisson process of rate 10 kbps. (6)We set the initial physical rate of all stations equal to 11 Mbps. (7)AC VO has the CWmin equals to 7, CWmax equals to 15, and IFSN equals to 2; AC BK has the CWmin equals to 31, CWmax equals to 1023, and IFSN equals to 7. A. Influence of Admission Control In this scenario, we want to show the importance of admission control. The admission control here includes not only the admission control of call entrance but also the regulation for entered real-time traffic. The regulation determines whether a traffic stream can contend the medium or not; a TS can contest the medium for sending packet only when TxUsedDn[AC VO] (or TxUsedUp[AC VO]) is smaller than TxAdDn[AC VO] (or TxAdUp[AC VO]). In addition to one QAP and two QSTAs generating background traffic in the. 19.

(28) Number of VoIP Calls. Call Numbers. 60 40. noAC AC. 20 0 1. 8. 15 22 29 36 43 50 57 64 71 78 85 92 99 Time (Sec). Figure 5.1: Scenario A: The number of calls as time goes on. original network, we will add one QSTA to the network every two seconds if possible (call arrival rate is 0.5 call/sec). We assume the queue size limitation is 50 to each AC and all the network resource is giving to the AC VO. The following we will compare the network performance when either the admission control mechanism is used or not. Fig. 5.1 shows us that the network can at most increase the VoIP calls to 17 when the CAC mechanism is used (because of the call entrance control). Although the calls number can unboundedly increase when there is no admission control, the collision rate will rapidly increase when the call number is more than 17 after 34th second(Fig. 5.4). Because of the high collision rate, we can observe that the network goodput without the CAC will less than the one with CAC after 34th second in Fig. 5.2. Before the 34th second, the goodput with the CAC mechanism is better than the no-CAC one because of the regulation and control message overhead. Nevertheless, this CAC regulation is helpful to control the collision probability(Fig. 5.4) and resource sharing. For example, Fig. 5.3 shows us that the throughput of background traffic is better with the CAC mechanism because the resource sharing is more fair. With these simulation results, we conclude that the admission control is necessary especially when supporting VoIP service. B. Influence of Host Mobility Mobility is a nature character in WLANs. This character will affect the trans20.

(29) Total Goodput of VoIP Sessions. Goodput(kbps). 1000 800 600. noAC. 400. AC. 200 0 1. 9. 17. 25. 33. 41. 49. 57. 65. 73. 81. 89. 97. Time(Sec). Figure 5.2: Scenario A: Total goodput of the WLANs either the CAC mechanism is applied.. Throughput(kbps). Throughput of Background Traffic. 40 30 noAC. 20. AC(17). 10 0 1. 10. 19. 28. 37. 46. 55. 64. 73. 82. 91 100. Time(Sec). Figure 5.3: Scenario A: Throughput of background traffic in the WLANs either the CAC mechanism is applied.. 21.

(30) No. of Collisions per-Sec. Average Collisions per-STA. 250 200 150. AC. 100. noAC. 50 0 1. 11. 21. 31. 41. 51. 61. 71. 81. 91. Time(Sec). Figure 5.4: Scenario A: Average collisions number per-QSTA per-second either the CAC mechanism is applied.. 1/4. 1/4. 1Mbits/s. 2Mbits/s. 1/4 3/4. 5.5Mbiits/s. 11Mbits/s. 3/4 1/4. 1/2. 1/4. 1/2. Figure 5.5: movement.. 22. 1/4.

(31) mission rate of stations, and will even cause the handoff problem. In this scenario, we assume all QSTAs move within a QAP. Thus, we use the following pattern to simulate the movement: every second, each non-AP QSTA has 50% probability to change it’s physical rate. If the decision of changing rate is taken, to increase or decrease the transmission rate has the same probability. Fig. 5.5 presents the transition diagram of this imitate movement. What we want to learn in this experiment are the influence of mobility and if our mechanism proposed in 3.2 will increase the performance or not. Therefore, we evaluate the average goodput (Fig. 5.6) and collisions (Fig. 5.7) per-QSTA per-second in this environment. In the Fig. 5.6, we can learn that the mobility function will decrease the network throughput(AC M) and using our third enhancement mechanism proposed in 3.2 will alleviate the goodput decreasing (AC ME). Fig. 5.7 shows that collisions number is proportion to goodput and QSTAs number. The reason is that the collision probability is inverse proportion to the transmission opportunity. The goodput degradation is large in our simulation when mobility function is added. This is because we use a high mobile condition. Therefore, the degradation won’t so serious if the network is more stable. In conclusion, the mobile condition will affect the network goodput, and our mechanism will moderate this degradation. C.Influence of Codec and Packetization Interval In this part, we want to discuss about the influence of codec and packetization interval. Although there are many works probe into this issue ([7, 10]), we made a small experiment. Fig. 5.8 shows the theoretical value of VoIP call numbers can be supported within an QAP computed using the MT computation equation mentioned in 3.1. In addition, Fig. 5.9 shows the simulated value of call numbers can be supported within an QAP when AC VO has queue size of 50 frames and dropping rate is limited by 0.02. With these information, we can figure out that the third mechanism in 3.2 may work well because that both the codec and the packetization interval may influence the number of phone calls within a QAP. D. Goodput Evaluation of Redirecting Packets to other queues In this experiment, we verify that how much improvement can be made by the second enhancement mentioned in chapter 4. From Fig. 5.10 and Fig. 5.11, we learn that the network performance will improved with the mechanism that redirect VoIP packets to other queue. Compare. 23.

(32) Average Goodput(kbps). 70 60 50. AC. 40. AC_M. 30. AC_ME. 20 10 0 5. 10. 15. 17. no. of VoIP calls. Figure 5.6: Scenario B: Average goodput per-QSTA per-second when WLAN has 5, 10, 15, 17 VoIP calls. AC in the figure presents the goodput under the condition which all QSTAs is static; AC M means the non-AP QSTA will move in the way we defined; AC ME shows the goodput improvement with our enhancement under the mobile environment .. 80. 60 AC 40. AC_M AC_ME. 20. 7 1. 1. 1. 0. 5. 0. 5. No. of Collsions per-Sec. Average collisions per-STA. no. of VoIP calls. Figure 5.7: Scenario B: Average collisions when WLAN has 5, 10, 15, 17 VoIP calls. The figure shows the condition of collision within 100 seconds within 100 seconds.. 24.

(33) Figure 5.8: The calculating number of VoIP calls an QAP can support with different conditions.. Figure 5.9: The number of VoIP calls an QAP can support when AC VO queues size is 50 frames and dropping rate is smaller than 0.02.. 25.

(34) Average goodput(kbps). Average Goodput Comparison. 80 60. AC. 40. AC_R. 20. AC_M_R. 0 5. 10. 15. 17. no. of VoIP calls. Figure 5.10: Scenario D: In this figure, AC R means there is a mechanism of redirecting packet to AC BE queue except original admission control. AC M R is the condition that using the redirect mechanism when mobility function is on. this experiment(Fig. 5.10) and scenario B(Fig. 5.6) that using different method to improve the performance degradation, we find the gain of this MAC enhancement is much better. The reason may be that there is no AC BE traffic in our simulated environment. Cooperate these two mechanism can greatly alleviate the problem cased by the mobility nature in WLANs. E. Enhancement to Downlink Traffic We verify the final MAC enhancement in chapter 4 in this experiment. Therefore, when QAP receive the uplink traffic of VoIP, it will send back the downlink traffic of the same call if possible. Fig. 5.12 and Fig. 5.13 figure out the simulation results of goodput and collision condition. In substance, this mechanism will improve the goodput of VoIP traffics because it may decreasing the possible contention number. In addition, the downlink traffic can be transmitted more smooth.. 26.

(35) Goodput (kbps). Total Goodput of 17 VoIP sessions. 1500 AC. 1000. AC_R 500. AC_M_R. 0 1. 9. 17 25 33 41 49 57 65 73 81 89 97 Time(Sec). Figure 5.11: Scenario D: This figure shows the goodput variation within 100 seconds. Average Goodput(kbps). when there are 17 VoIP calls.. 70 60 50 40. AC. 30. AC_EQAP. 20 10 0 5. 10. 15. 17. No. of VoIP calls. Figure 5.12: Scenario E: The average goodput enhancement per-QSTA per-second when we enhance the QAP to profit the downlink traffic.. 27.

(36) No. of collisions per-Sec. Average collisions per-STA. 80 60 AC. 40. AC_EQAP. 20 0 1. 2. 3. 4. No. of VoIP calls. Figure 5.13: Scenario E: The average collision numbers per-QSTA per-second either of enhancing the QAP to profit the downlink traffic or not.. 28.

(37) Chapter 6 Conclusions In this paper we describe the novel protocol to enhance the performance of VoIP services by integrate the SIP call setup signaling and 802.11e QoS mechanism. IEEE 802.11e is in the final stage to become a standard, so we choice to make good use of it to solve the QoS problem in WLANs with minimum modification. We think the cross-layer protocol design to facilitate the process of applications will be a trend in future. In addition, we present some MAC enhancement to facilitate the VoIP service under WLANs. Moreover, the simulation results show that our adjustment during transmission and MAC enhancement will work well. The future work may focus on several aspects: (1)solve the handoff problem; (2)experiment in real environment; (3)extend the architecture to other call signaling system.. 29.

(38) Bibliography [1] http://www.cisco.com/en/US/products/hw/phones/ps379/ps5056/index.html. Technical report. [2] http://www.motorola.com/motoinfo/product/details/0,,48,00.html. Technical report. [3] IEEE 802.11e/D8.0, Draft Amendment to Part 11: Wireless Medium Access Control(MAC) and Physical Layer(PHY) specifications: Medium Access Control(MAC) Quality of Service(QoS) Enhancements. June 2003. [4] F. Anjum, M. Elaoud, D. Famolari, A. Ghosh, R. Vaidyannthan, A. Dutta, and P. Ageawal. Voice Performance in WLAN Networks - An Experimental Study. In IEEE Globecom’03, 2003. [5] D. Conllins. Carrier Grade Voice over IP Second Edition. McGraw-Hill Companies, Inc, 2003. [6] S. Garg and M. Kappes. Admission Control for VoIP Traffic in IEEE 802.11 Networks. In IEEE Globecom’03, 2003. [7] S. Garg and M. Kappes. Can I Add a VoIP Call ? In IEEE ICC’03, 2003. [8] A. Grilo, M. Macedo, and M. Nunes. A Scheduling Algorithm for QoS Support in IEEE 802.11e Networks. IEEE Wireless Communications, June 2004. [9] T. Hiraguri, T. Ichikawa, M. Iizuka, and M. Morikura. Novel Multiple Access Protocol for Voice over IP in Wireless LAN. In IEEE ISCC’02, 2002. [10] D. P. Hole and F. A. Tobagi. Capacity of an IEEE 802.11b Wireless LAN supporting VoIP. In in proc. of IEEE ICC’04, 2004.. 30.

(39) [11] F.-W. Jung, R. Muddumbai, D. Montgomery, and H.-K. Kahng. Performance Evaluation of Two Layered Mobility Management using Mobile IP and Session Initiation Protocol. In IEEE Globecom’03, 2003. [12] L. Lim, R. Malik, P. Tan, C. Apichaichalermwongse, K. Ando, and Y. Harada. A QoS scheduler for IEEE 802.11e WLANs. In IEEE CCNC’04, 2004. [13] M. Malli, Q. Ni, T. Turletti, and C. Brakat. Adaptive Fair Channel Allocation for QoS Enhancement in IEEE 802.11 Wireless LANs. In IEEE ICC’04, 2004. [14] T. D. T. Ming He, D. Zhao, and V. Kezys. Ad Hoc Assisted Handoff for Real-time Voice in IEEE 802.11 Infrastructure WLANs. In IEEE WCNC’04, 2004. [15] J. Rosenberg, H. Schulzrinne, E. Schooler, M. Handley, G. Camarillo, A. Johnston, J. peterson, and R. Sparks. SIP: Session Initiation Protocol, RFC3261 in IETF. June 2002. [16] Y. Xiao, H. Li, and sunghyun Choi. Protection and Guarantee for Voice and Video Traffic in IEEE802.11e Wireless Lans. In IEEE Infocom’04, 2004. [17] J. Yu, S. Choi, and J. LEE. Enhancement of VoIP over IEEE 802.11 WLAN via Dual Queue Strategy. In IEEE ICC’04, 2004.. 31.

(40) Curriculum Vita Pei-Yeh Wu (phwu@csie.nctu.edu.tw) received his B.S. degree in Computer Science from the National Chiao-Tung University, Taiwan, in 2003. His research interests include wireless network, sensor network and QoS issue.. 32.

(41)