Abstract:
A method for establishing a voice over IP (VoIP) call in a wireless local-area network (WLAN) access point includes an access point receiving a first signal and forwarding the first signal to a station. After forwarding the first signal, the access point receives a request from the station. In response to the request, the access point allocates a resource for the station. Then, the access point responds to the station with a response indicating that the resource is allocated. Subsequent to the access point responding to the station, the access point receives a last signal from the station.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of the Invention  
         [0002]     The present invention relates to computers, and more specifically, to wireless local area networks.  
         [0003]     2. Description of the Prior Art  
         [0004]     Recently, there have been two major trends in the area of communications. First, IEEE 802.11 wireless local-area networks (WLANs) have become widely deployed in the world. Second, due to the growth of Internet bandwidth, real-time audio and video applications have become more mature and more popular. The combined effect has made voice over IP (VoIP) across WLANs possible.  
         [0005]     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 and MOTOROLA MPx). The above observation has raised an interesting issue: how do WLANs support quality of service (QoS) and call admission control (CAC) for VoIP traffic? The IEEE 802.11 Task Group E(802.11e) has been formed to expand the current 802.11 MAC protocol to support applications with QoS requirements. In addition, a session initiation protocol (SIP) has been widely accepted as the signaling protocol for VoIP to handle the setup, modification, and teardown of VoIP sessions.  
         [0006]     Prior art exists that focuses on improving VoIP traffic in WLAN environments. Sachin Garg and Martin Kappes,  Admission Control for VoIP Traffic in IEEE  802.11  Networks, IEEE Globecom&#39; 03, 2003 claims that admission control is critical to protect VoIP traffic because resources in a WLAN cell is limited. A channel utilization estimation (CUE) is proposed to determine whether to accept a new call. Alternatively, giving priority to VoIP traffic helps improve performance, as disclosed in Takefumi Hiraguri, Takeo Ichikawa, Masataka Iizuka, and Masahiro Morikura,  Novel Multiple Access Protocol for Voice over IP in Wireless LAN, IEEE ISCC&#39; 02, 2002. Some art points out that the bottleneck is at the access point (i.e., down link traffic). In Farooq Anjum, Moncef Elaoud, David Famolari, Abhrajit Ghosh, Ravichander Vaidyannthan, Ashutosh Dutta, and Prathima Ageawal,  Voice Performance in WLAN Networks—An Experimental Study, IEEE Globecom&#39; 03, 2003, a BC-PQ (backoff control and priority queue (BC-PQ) mechanism is proposed to give priority to voice traffic over data traffic and assign zero backoff time to voice packets in access points. On the other hand, Jeonggyun Yu, Sunghyun Choi, and Jaehwan LEE,  Enhancement of VoIP over IEEE  802.11  WLAN via Dual Queue Strateg,. In IEEE ICC&#39; 04, 2004 proposes to separate real-time and non-real-time packets into two queues, and an access point (AP) always processes a real-time queue first whenever it is not empty. A number of concurrent VoIP sessions that can be supported in a WLAN is evaluated in Sachin Garg and Martin Kappes,  Can I Add a VoIP Call ? IEEE ICC&#39; 03, 2003 and David P. Hole and Fouad A. Tobagi,  Capacity of an IEEE  802.11b  Wireless LAN supporting VoIP, in proc. of IEEE ICC&#39; 04, 2004. It is reported that besides the bandwidth limitation of the physical layer, the codec, packetization 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.  
         [0007]     On the standardization track, the IEEE 802.11 working group R (802.11r) is currently developing fast roaming mechanisms. Fin-Woo Jung, Ranganathan Muddumbai, Doug Montgomery, and Hyun-Kook Kahng, Performance Evaluation of Two Layered Mobility Management using Mobile IP and Session Initiation Protocol, IEEE Globecom&#39;03, 2003 proposes a structure to integrate Mobile IP with SIP to assist VoIP mobility, while Terence D. Todd Ming He, Donhmei Zhao, and Vytas Kezys, Ad Hoc Assisted Handoff for Real-time Voice in IEEE 802.11 Infrastructure WLANs, IEEE WCNC&#39;04, 2004 suggests using ad hoc-assisted handoff to meet the QoS requirement of VoIP during handover. IEEE 802.11e aims at enhancing its MAC mechanism to support QoS. Several works have studied using 802.11e to improve multimedia transmission under WLAN. QoS schedulers based on HCCA of IEEE 802.11e are proposed in Antonio Grilo, Mario Macedo, and Mario Nunes, A Scheduling Algorithm for QoS Support in IEEE 802.11e Networks, IEEE Wireless Communications, June 2004 and L. W. Lim, R. Malik, P. Y. Tan, C. Apichaichalermwongse, K. Ando, and Y. Harada, A QoS scheduler for IEEE 802.11e WLANs, IEEE CCNC&#39;04, 2004. Some works discuss how to ameliorate EDCA in IEEE 802.11e to facilitate multimedia transmission. Mohammad Malli, Qiang Ni, Thierry Turletti, and Chadi Brakat, Adaptive Fair Channel Allocation for QoS Enhancement in IEEE 802.11 Wireless LANs, IEEE ICC&#39;04, 2004 extends the basic EDCA by using an adaptive fast backoff mechanism along with a window doubling mechanism at busy period. In Yang Xiao, Haizhon Li, and Sunghyun Choi, Protection and Guarantee for Voice and Video Traffic in IEEE802.11e Wireless Lans, IEEE Infocom&#39;04, 2004, 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 an AP must adjust lower-priority access categories&#39; contention windows, arbitration inter-frame spacing (AIFS), and so forth, to protect real-time sessions from colliding by those that do not require admission control.  
         [0008]     802.11e MAC Protocol  
         [0009]     The current IEEE 802.11 MAC has no means of differentiating traffic streams (TSs) 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 traffic. The IEEE 802.11 Working Group E has proposed a hybrid coordination function (HCF) for both ad-hoc and infrastructure modes. Several enhancements are introduced in 802.11e. First, a concept called transmission opportunity (TXOP) is introduced, which is a period of time during which a QoS enhanced stations (QSTA—a station that supports 802.11e, such as a caller or callee) 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 hybrid coordinator (HC). Second, IEEE 802.11 e supports traffic differentiation by giving traffic streams priorities. Third, it allows a TS to specify its traffic characteristic.  
         [0010]     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, EDCA is of primary consideration.  
         [0011]     IEEE 802.11e EDCA  
         [0012]     To differentiate services, IEEE 802.11e adopts the eight user priorities in 802.1D and maps then to four access categories (ACs) as shown in Table 1. EDCA supports these ACs by four separated queues in both QAP (an AP that supports 802.11e) and QSTA, as illustrated in  FIG. 1 . 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 its own arbitration inter-frame space (AIFS[i]), initial window size (CWmin[i]), and maximum contention window size (CWmax[i]). If multiple queues finish their backoff simultaneously, a 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.  
                               TABLE 1                       802.1D   802.1D   802.11e   802.11e AC           Priority   Designation   AC Index   Designation   Comment                   1 (low)   BK   01   AC_BK   Background       2   —       AC_BK   Background       0   BE   00   AC_BE   Best Effort       3   EE       AC_BE   Best Effort       4   CL   10   AC_VI   Video       5   VI       AC_VI   Video       6   VO   11   AC_VO   Voice       7 (high)   NC       AC_VO   Voice                  
 
         [0013]     An EDCA parameter set information element, as shown in  FIG. 2 , 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 a TXOP limit equals zero, a QSTA can transmit only one packet each time it gains the TXOP.  
         [0014]     Admission Control in EDCA  
         [0015]     A QAP uses an admission control mandatory (ACM) subfield advertised in the EDCA parameter set to indicate whether admission control is required for each AC. A QSTA can send an add traffic stream (ADDTS) request to the QAP to request adding a new traffic stream by specifying its direction (uplink, downlink, bidirectional, or direct) and providing a traffic specification (TSPEC) information element as shown in  FIG. 3 . Some important fields in the TSPEC are discussed below:  
         [0016]     Minimum Data Rate: the lowest data rate (in bits per second) to transport MSDUs.  
         [0017]     Mean Data Rate: the average data rate (in bits per second) to transport MSDUs.  
         [0018]     Peak Data Rate: the maximum allowable data rate (in bits per second) to transport MSDUs.  
         [0019]     Minimum PHY Rate: the desired minimum physical rate for this traffic stream.  
         [0020]     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.  
         [0021]     On receiving an ADDTS request, the QAP may decide to accept or reject it. In the former case, the QAP will calculate a medium time (MT) for this traffic stream per beacon interval and reply with an ADDTS response containing this information; otherwise, an ADDTS response including rejection information is sent as a reply. For QAP and each QSTA, they keep the total MT and consumed MT of each AC. Only when the former is larger 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 traffic stream ID (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.  
         [0022]     SIP and SDP  
         [0023]     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 session description protocol (SDP, which is specified in RFC 2327. It does not provide a means for transporting or advertising. RFC 3264 describes how SDP co-works with SIP.) to describe session characteristics and real-time transport protocol (RTP, which is often accompanied with RTP control protocol—RTCP—to provide transport services to support real-time applications.) to send traffic after call setup.  
         [0024]     SIP is designed to keep signaling as simple as possible.  FIG. 4  shows one example of call establishment. When a caller  402  wants to make a VoIP connection with a callee  404 , the caller  402  sends an “INVITE” including any codecs that the caller  402  supports in a SDP message body. An example in the “INVITE” signal is shown below with G.726 ( 2 ), G.723 ( 4 ), and G.728 ( 15 ) as the selections (numbers in parentheses are payload types) and  123  as the receive port:  
         [0025]     INVITE: sip: Mary@station2.nthu.edu.tw SIP/2.0  
         [0026]     From: Caller&lt;sip: Susan@station1.nctu.edu.tw&gt;; tag=abc123  
         [0027]     To: Callee&lt;sip: Mary@station2.nthu.edu.tw&gt; 
         [0028]     Cseq: 1 INVITE  
         [0029]     Content-Type: application/sdp  
         [0030]     Content-Disposition: session  
         [0031]     v=0  
         [0032]     o=Susan 123 001 IN IP4 station1.nctu.edu.tw  
         [0033]     s= 
         [0034]     c=IN IP4 station1.nctu.edu.tw  
         [0035]     t=0 0  
         [0036]     m=audio 123 RTP/AVP 2 4 15  
         [0037]     a=rtpmap 2 G726-32/8000  
         [0038]     a=rtpmap 4 G723/8000  
         [0039]     a=rtpmap 15 G728/8000  
         [0040]     If the callee  404  decides to accept the request, it replies with “Ringing” and an “OK” signal to the caller  402 . The “OK” signal contains the callee&#39;s choice of codec. In the example of the “OK” signal below, the callee  404  chooses G.728 (15), using the receive port of 888, a port number of 0 indicating a rejection:  
         [0041]     SIP/2.0 200 OK  
         [0042]     From: Caller&lt;sip: Susan@station1.nctu.edu.tw&gt;; tag=abc123  
         [0043]     To: Callee&lt;sip: Mary@station2.nthu.edu.tw&gt; 
         [0044]     Cseq: 1 INVITE  
         [0045]     Content-Type: application/sdp  
         [0046]     Content-Disposition: session  
         [0047]     v=0  
         [0048]     o=callee 456 001 IN IP4 station2.nthu.edu.tw  
         [0049]     s= 
         [0050]     c=IN IP4 station2.nthu.edu.tw  
         [0051]     t=0 0  
         [0052]     m=audio 0 RTP/AVP 2  
         [0053]     m=audio 0 RTP/AVP 4  
         [0054]     m=audio 888 RTP/AVP 15  
         [0055]     In view of the related art above, there is a need for an improved system for VoIP having better QoS over WLAN environments.  
       SUMMARY OF THE INVENTION  
       [0056]     It is therefore a primary objective of the invention to provide a method for establishing a voice over IP call in a WLAN.  
         [0057]     Briefly summarized, the invention includes an access point receiving a first signal and forwarding the first signal to a station; after forwarding the first signal, the access point receiving a request from the station; in response to the request, the access point allocating a resource for the station; the access point responding to the station with a response indicating that the resource is allocated; and subsequent to the access point responding to the station, the access point receiving a last signal from the station.  
         [0058]     These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment that is illustrated in the various figures and drawings.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0059]      FIG. 1  is a diagram of management of access categories in EDCA according to the related art.  
         [0060]      FIG. 2  illustrates an EDCA parameter set information element according to the related art.  
         [0061]      FIG. 3  illustrates a TSPEC information element according to the related art.  
         [0062]      FIG. 4  illustrates one example of call establishment according to the prior art.  
         [0063]      FIG. 5  illustrates QoS architecture integrating SIP with IEEE 802.11e according to the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0064]     The present invention supports voice over IP (VoIP) services over wireless local-cara network (WLAN) environments. In particular, the present invention integrates IEEE 802.11e with session initialization protocol (SIP) to conduct call admission control over WLAN environments and support quality of service (QoS) for VoIP calls. The present invention&#39;s cross-layer design can maintain the QoS of VoIP services. Moreover, the present invention can also increase the number of VoIP sessions supported under an access point (AP) without compromising QoS. Although the invention is described in terms of IEEE 802.11e and SIP, the improvements of the invention can be applied any VoIP system.  
         [0065]     In the invention, SIP is used for call setup and management. 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. The present invention aims to provide a 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.  
         [0066]     Call Establishment  
         [0067]      FIG. 5  illustrates QoS architecture integrating SIP with IEEE 802.11e according to the present invention. When a caller  502  under access point QAP 1   504  wants to establish a VoIP connection with a callee  508  at access point QAP 2   506 , the caller  502  can send an “INVITE” signal with a message (e.g., an SDP message) containing necessary codec information to the callee  508 . The access points QAP 1   504  and QAP 2   506 , on receiving this “INVITE” signal (refer to steps A and B in  FIG. 5 , shown as boxes), do pre-resource reservation and may filter out any codecs that they cannot support due to bandwidth constraints. When the callee  508  receives this “INVITE” signal (refer to steps C and D), the callee  508  exchanges a request and a response e.g., 802.11e ADDTS request and response) with access point QAP 2   506 . This can prevent ghost rings (A ghost ring happens when a user can not communicate with the other party as he/she picks up a ringing phone. Shortage of bandwidth is often a reason for ghost rings in VoIP applications.). After exchanging ADDTS messages, the callee  508  can send “Ringing” and “OK” signals to the caller  502 . The “OK” signal contains the codec selected by the callee  508 . After receiving the “OK” signal, the caller  502  will exchange ADDTS request and response messages with access point QAP 1   504  (refer to steps E and F, in  FIG. 5 ). If these steps are successful, an “ACK” signal will be sent to from the caller  502  to the callee  508  as a reply.  
         [0068]     In the following, the detailed actions taken at steps A, B, C, D, E, and F, shown as boxes in  FIG. 5 , will be explained.  
         [0069]     Referring to step A of  FIG. 5 , the access point QAP 1   504  conducts pre-resource reservation for the caller  502 . Generally, an access point (QAP) has to broadcast the physical layer (PHY) rates that it can support in its beacon frames. When a QoS enhanced station (QSTA), such as the caller  502  or callee  508 , 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.  
         [0070]     To conduct pre-resource reservation according to the present invention, the access point QAP 1   504  maintains a packet size table (PST) as shown below, which contains the packet sizes when different codecs and packetization intervals (PI) are used.  
                                                                                       TABLE 2                                       Data               Rate   Packetization Interval (ms)            Codec   (kbps)   5   10   20   30   40                    G.711   64   114   154   234   314   394       G.726   16   84   94   114   134   154           32   94   114   154   194   234       G.725   16   84   94   114   134   154       G.723.1   5.3   —   —   —   94   —           6.3   —   —   —   98   —                  
 
         [0071]     For example, in G.726 with a sampling rate of 32 kbps, if a packetization interval of 20 ms is used, then 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 are well known. 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, the access point QAP 1   504  can compute a medium time (MT) that should be reserved for the traffic stream per beacon interval (BI) as follows:  
         [0072]     MT=(total time needed per BI)  
         [0073]     =(time to send one packet)*(no. packets per BI)*(surplus bandwidth allowance)  
         [0074]     =[(PLCP preamble and header)+payload+SIFS+ACK] 
         [0075]     *(BI/PI)*(surplus bandwidth allowance)  
         [0076]     =[(packet size)=(min PHY rate)+2*PLCP/Mbps+(ACK/min PHY rate)+SIFTS] 
         [0077]     *(BI=PI)*(surplus bandwidth allowance) (1)  
         [0078]     According to 802.11, SIFS is 10 microseconds, an “ACK” packet is 14 bytes, and the 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 a statistical sense). In the present invention, the surplus bandwidth allowance is about 1.1. For example, when BI is 1 sec and min PHY rate is 11 Mbps, in G.726 with 32 kbps and PI of 20 msec, then MT=[154/11(bytes/Mbps)+2*24(bytes/Mbps)+14/11(bytes=Mbps)+10 microseconds]*(1000/20)*1:1=28.39 ms.  
         [0079]     For each codec in the “INVITE” signal, if its MT exceeds the remaining MT of the access point QAP 1   504 , the codec is removed from the codec list. In case the remaining resource in the access point QAP 1   504  does not allow the access point QAP 1   504  to support any codec, the access point QAP 1   504  can drop the “INVITE” signal silently or reply with an SIP response to the caller  502  with a status code of “480”, which means “temporarily unavailable.” Also note that since voice communications are bidirectional, the access point QAP 1   504  should reserve 2*MT max , where MT max  is the maximum time required by all codecs in the list.  
         [0080]     Referring to step B of  FIG.5 , the access point QAP 2   506  conducts pre-resource reservation for the callee  508 . The calculation of medium time at the callee  508  when receiving the “INVITE” signal is similar to what is already described above. The access point QAP 2   506  also filters out those codecs that it cannot support from the “INVITE” signal and reserves the maximum required bandwidth. The “INVITE” signal is then forwarded to the callee  508  if at least one codec can be supported.  
         [0081]     Referring to step C of  FIG.5 , an ADDTS request is made by the callee  508 . After determining the codec to use, the callee  508  can send a bidirectional ADDTS request (i.e., request and response) to the access point QAP 2   506  by including a TSPEC element. VoIP service requirements can be conveyed with the following fields in the TSPEC element:  
         [0082]     Minimum Data Rate=the acceptable longest packetization interval of the corresponding codec.  
         [0083]     Mean Data Rate=the packetization interval selected by the callee  508 .  
         [0084]     Maximum Data Rate=the acceptable shortest packetization interval.  
         [0085]     Medium Time=the codec selected by the callee  508 .  
         [0086]     With this information, the access point QAP 2   506  can do call admission control as described below.  
         [0087]     Referring to step D of  FIG.5 , call admission control is performed at the access point QAP 2   506 . According to the callee&#39;s ADDTS request and the packet size information (see Table 2), the access point QAP 2   506  can compute the required medium time via Eq. (1). Note that with a bidirectional request, the same medium time should be applied to both the uplink and the downlink directions. In order to conduct call admission control, the access point QAP 2   506  should maintain the following variables:  
         [0088]     TXOPBudget[AC i ]: The remaining bandwidth that can be allocated by access category AC i , i=0 . . . 3;  
         [0089]     TxAdDn[AC i ][TSID]: The admitted medium time for stream TSID of access category AC i  in the downlink direction;  
         [0090]     TxAdUp[AC i ][TSID]: The admitted medium time for stream TSID of access category AC i  in the uplink direction; 
 
 TxAdDn[AC i ]: This value is set to  
       ∑     ∀   TSID         
 
 TxAdDn[AC i ][TSID], to record the overall resource allocated to access category AC i  in the downlink direction; and 
 
         [0091]     TxUsedDn[AC i ]: The summation of used medium time of all downlink streams of access category AC i .  
         [0092]     Initially, TXOPBudget[AC i ] contains all the bandwidth (in terms of medium time) that is reserved for access category AC i . Whenever a new stream is added, the corresponding resource is subtracted from TXOPBudget[AC i ], and the resource is assigned to TxAdDn[AC i ][TSID] and/or TxAdUp[AC i ][TSID]. In addition, each QSTA should maintain the following variables:  
         [0093]     TxAdUp[AC i ][TSID]: The admitted medium time for stream TSID of access category AC i  in the uplink direction in this station (STA) per beacon interval (BI); 
 
 TxAdUp[AC i ]: This value is set to  
       ∑     ∀   TSID         
 
 TxAdUp[AC i ][TSID], to record the overall resource allocated to access category AC i  of this STA in the uplink direction; and 
 
         [0094]     TxUsedUp[AC i ]: The summation of used medium time of all uplink streams of access category AC i .  
         [0095]     Resource reservation at QAP 2  is done as follows. First, the value of TXOPBudget[AC i ]2*MT is computed. If the value is non-negative, there is sufficient resource to support this call the following can be set:  
         [0096]     TXOPBudget[AC i ]=TXOPBudget[AC i ]−2*MT;  
         [0097]     TxAdDn[AC i ][TSID]=MT;  
         [0098]     TxAdUp[AC i ][TSID]=MT; and  
         [0099]     TxAdDn[AC i ]=TxAdDn[AC i ]+TxAdDn[AC i ][TSID].  
         [0100]     MT is computed from Eq. (1) based on the information of codec, PI, min PHY rate, etc., provided by the TSPEC. If there is insufficient resource, the QAP can choose the next larger PI (if possible), re-compute a new MT, and repeat the above testing, until a satisfactory PI is found. Thus, the access point QAP 2   506  will reply with an ADDTS response to the callee  508  with a “Mean Data Rate”=PI and a “Medium Time”=MT in the TSPEC. If there is insufficient resource, then an ADDTS response is sent in reply with “Medium Time”=0.  
         [0101]     At the callee&#39;s side, if an ADDTS response with a positive “Medium Time” is received, then the QSTA sets its TxAdUp[AC i ][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  508  should reply with a response signal, that is the “OK” signal, having the proper status code to the caller  502 .  
         [0102]     Referring to step E of  FIG.5 , the caller  502  performs an ADDTS request. When the caller  502  receives the “OK” signal with codec information from the callee  508 , the caller  502  sends an ADDTS request to the access point QAP 1   504 . This is similar to the process at the callee  508  described with reference to step C, and further description is omitted.  
         [0103]     Referring to step E of  FIG.5 , the access point QAP 1   504  performs call admission control. This action is similar to the call admission control performed at the access point QAP 2   506  described with reference to step D. If the caller  502  receives a successful ADDTS response, the caller  502  will send an “ACK” signal to the callee  508 . 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 call admission control in steps D and F. Finally, although it is assumed that both the caller  502  and the callee  508  are under WLANs, the above procedure should work well if any side is not under a WLAN.  
         [0104]     Resource Readjustment During Transmission  
         [0105]     The above steps are for the setup of new calls. However, during transmissions, a stream may dynamically change its bandwidth requirement. In this subsection, the steps to be taken alleviate such problems are introduced.  
         [0106]     Regarding estimation of downlink PI by the access points QAP 1   504  and QAP 2   506 , 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 the caller  502  or the callee  508  to access point QAP 1   504  or QAP 2   506 , respectively) is accurate, the MT reserved for the downlink direction is only an approximation. To solve this problem for each stream TSID, the access point QAP 1   504  or QAP 2   506  is required to observe packets from the other side for several beacon intervals and estimate the actual PI being used. After estimating the actual PI, the access point QAP 1   504  or QAP 2   506  should calculate the MT according to Eq. (1) for this stream and then update TxAdDn[AC VO][TSID] and TxAdDn[AC VO].  
         [0107]     Regarding adjustment for PHY rate change at QSTAs (i.e., caller  502  and callee  508 ), 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, the QSTA can send an updated 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: by allocating more medium time for the stream if it still has more resource available, or by suggesting a longer PI to reduce the required medium time of the corresponding traffic stream. If the request succeeds, a new medium time will be sent in reply; otherwise, the QAP will reply with the stream&#39;s original medium time. In the latter case, the call may suffer from lower quality.  
         [0108]     Regarding mechanisms to support more VoIP sessions, when a WLAN is very congested or when there are more new VoIP calls required to join the WLAN, resource consumption of current calls can be reduced. In such a situation, a QAP (i.e., access point QAP 1   504  or QAP 2   506 ) can send a beacon frame by carrying such a notification to its QSTAs (i.e., caller  502  or callee  508 ). A QSTA may respond in two ways:  
         [0109]     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  
         [0110]     ADDTS request; or  
         [0111]     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.  
         [0112]     The present invention provides a way to enhance the performance of VoIP services by integrating the SIP call setup signaling and the 802.11e QoS mechanism. It should be noted that each of the access points QAP 1   504  and QAP 2   506  can include all of the functionality described above. That is, each access point QAP 1   504  and QAP 2   506  can handle one or more callers and/or callees in any combination.  
         [0113]     Those skilled in the art will readily observe that numerous modifications and alterations of the device and method may be made while retaining the teachings of the invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.