CARRYING VOICE ON IEEE 802.11 WIRELESS LOCAL AREA NETWORKS THESIS Submitted in Partial Fulfillment of the REQUIREMENTS for the Degree of MASTER OF SCIENCE (Telecommunication Networks) at the POLYTECHNIC UNIVERSITY by Nabeel Cocker June 2001 _________________ Advisor _________________ Date _________________ Department Head _________________ Date Copy No._______ 1 AN ABSTRACT CARRYING VOICE ON IEEE 802.11 WIRELESS LOCAL AREA NETWORKS by Nabeel Cocker Advisor: Malathi Veeraraghavan Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science (Telecommunications Networks) January 2001 The IEEE 802.11 MAC protocol uses polling to support real-time services in conjunction with a random-access scheme for non-real-time services. Commercial interest has predominantly been in its support for data services. This work considers the question of how to support interactive voice services in wireless packet-switched networks that use such MAC protocols. A connection admission control procedure to control the number of voice calls admitted to the polling list is proposed. Based on the number admitted, buildout (voice reconstruction) delays are computed and signaled to the receiving ends of voice calls. We provide analytical formulations for number of voice calls and build-out delay under assumptions of constant resource allocation and variable resource allocation. With larger inter-poll periods, more voice calls can be accommodated, but at the expense of increased delay. We analyze operation of such networks. For example, our analysis shows that with constant bit rate resource allocation, with an inter-poll period of 90 ms, a maximum of 26 voice calls can be handled with a worst-case delay of 303 ms, whereas with an inter-poll period of 60 ms, a maximum of 17 voice calls can be handled with a worst-case delay of 213 ms. More calls can be supported with variable bit rate allocation 2 that takes advantage of silences in voice traffic at the expense of increased delay. We also carry out a loss analysis that demonstrates the need for error correction of voice packets. 3 Table of Contents List of Figures…………...……………………………………………...…..v List of Tables………………………………………………………………. 1.0 2.0 3.0 vi Introduction…………………………………………………………1 IEEE 802.11 Overview.……………………………….…………… 4 2.1 Components of the 802.11 architecture……………………. 4 2.1.1 Integration with wired LANS……………………… 6 2.2 MAC Services……………………………………………… 9 2.2.1 Asynchronous data service………………………….9 2.2.2 Security services…………………..……………..… 9 2.3 MAC frame formats………………………………………... 9 2.3.1 General frame format………………………………. 10 2.3.1.1 Frame control field……………………….. 10 2.3.1.2 Duration ID field…………………………. 12 2.3.1.3 Address fields……………………………..12 2.3.1.4 Sequence control field…………………….14 2.3.1.5 Frame body field…………………………. 14 2.3.1.6 FCS field…………………………………. 15 2.3.2 Format of individual frame types…………………... 15 2.3.2.1 Control frames…………………………… 15 2.3.2.1.1 RTS frame………………….. 15 2.3.2.1.2 CTS frame………………….. 16 2.3.2.1.3 Ack frame…………………...16 2.3.2.1.4 CF-End frame……………….16 2.3.2.2 Data frames………………………………….17 2.3.2.3 Management frames………………………... 17 2.4 Functional description of MAC sublayer…………………... 17 2.4.1 Distributed coordination function………………….. 18 2.4.2 Point coordination function…………………………23 Proposed method for carrying interactive voice in 802.11 LANs…. 27 3.1 Types of applications and networks suited to serving them.. 27 3.1.1 Real-time applications……………………………... 27 3.1.2 Non-real-time applications………………………… 28 3.2 Design choices………………………………………………29 3.2.1 Network architecture……………………………….. 29 3.2.1.1 Voice gateway………………………………30 3.2.2 Polling schemes……………………………………. 31 3.2.3 User-plane actions…………………………………. 33 3.2.3.1 Fixed or variable sized packets…………... 34 3.2.3.2 Timing method…………………………… 34 3.2.3.3 Protocol stack…………………………….. 35 3.2.3.4 Polling frequency………………………… 36 3.2.3.5 Termination of CP and CFP……………… 36 3.2.3.6 Whether error correction is needed………. 37 3.2.4 Control place actions………………………………..38 3.2.4.1 Computation of max. voice calls………… 40 4 4.0 5.0 6.0 3.2.4.2 Computation of build-out delay………….. 43 3.2.5 Management plane…………………………………..51 Analysis……………………………………………………………..53 4.1 Numerical values for system variables…………………….. 53 4.2 Numerical values for maximum number of calls…………... 53 4.3 Delay results………………………………………………...55 4.4 Error analysis………………………………………………..58 Simulation………………………………………………………….. 62 Conclusion…………………………………………………………. 66 Appendix A: Simulation code……………………………………………… 67 References…………………………………………………………………. 83 5 List of Figures 2.1 Basic Service Set……………………………………………………5 2.2 Distribution System………………………………………………... 6 2.3 Connecting to other 802 LANs…………………………………….. 7 2.4 MAC Frame Format………………………………………………... 10 2.5 Frame Control Field………………………………………………... 10 2.6 Sequence Control Field…………………………………………….. 14 2.7 RTS Frame………….……………………………………………… 15 2.8 CTS Frame…………………………………………………………. 16 2.9 Ack Frame………………………………………………………….. 16 2.10 CF-End Frame…..………………………………………………….. 16 2.11 Management Frame…………………………………………………17 2.12 Transmission of MPDU without RTS/CTS…..…………………..... Error! Bookmark not defined. 2.13 Transmission of MPDU using RTS/CTS..…………………………. 22 2.14 Point Coordination Frame Transfer...…………………………….... 24 2.15 Stretching…………………………………………………………... 26 3.1 Proposed Architecture………………………………………………30 3.2 Polling List Formation – Scheme 1…….………………………….. 32 3.3 Polling List Formation – Scheme 2.…….…………………………..32 3.4 Build-out delay………………………………………………..…….43 3.5 Computation of Maximum Delay of kth call for k1 to k2…………. 46 4.1 Maximum Number of Voice Calls in CBR mode………………….. 54 4.2 Total Delay in CBR mode…………………………………………..55 4.3 Total Delay for the VBR Mode of Operation (2 Mbps)…………… 56 4.4 Total Delay for the VBR Mode of Operation (11 Mbps)………….. 58 4.5 Model of a Wireless Channel………………………………………. 59 4.6 Packet Error Rates…………………………………………………..61 5.1 Simulation results with loss of 10-3………………………..………..64 6 List of Tables 2.1 2.2 3.1 3.2 3.3 4.1 4.2 4.3 5.1 Valid Type/Subtype Combinations………………………………… 11 To DS/From DS……………………………………………………. 13 Categorization of Applications…………………………………….. 27 Parameters………………………………………………………….. 39 Voice Models………………………………………………………. 42 Parameter Set 2…………………………………………………….. 53 Maximum Number of Voice Calls…………………………………. 55 Parameters for Burst of Error Models……………………………… 58 Comparison of CBR and VBR modes……………………………... 65 7 1.0 Introduction The IEEE 802.11 wireless LAN [1] is gaining popularity for data applications in campus networks, such as in university campuses and airports. Data rates of these indoor wireless LANs are in the order of 11 Mbps, which is considerably higher than outdoor wireless data services offered through cellular base stations. However, while the use of 802.11 LANs for Internet applications such as web browsing and electronic mail is increasing, there appears to be no immediate commercial interest in using these LANs to carry interactive voice or other real-time traffic. This is evident in that most commercially-available offerings only implement the 802.11 mode of operation that supports data services, called the Distributed Coordination Function (DCF) mode, and not the second 802.11 mode of operation, designed for real-time services, called the Point Coordination (PCF) mode. The goal of this work is to determine whether the 802.11 PCF mode is indeed suitable for supporting interactive voice services. This mode of operation uses a polling scheme to provide resource guarantees for real-time sessions. Therefore, more generally, the results of our work should be adaptable to any polling-based MAC scheme. Wireless links are typically shared in contrast to point-to-point cables. This implies that Medium Access Control (MAC) protocols are needed for resource sharing on wireless links. Different types of MAC protocols are needed for different types of services. For delay-insensitive data services, a simple random access MAC protocol is sufficient. On the other hand, to support delay-sensitive interactive voice traffic, more sophisticated MAC protocols, with resource reservation, are needed. Resources can be reserved on a fixed “circuit-like” basis for the duration of a call as is done in cellular 8 networks (where a time slot or frequency is dedicated to a call), or on a “virtual circuit” basis. “Virtual circuits” are connections in a packet-switched connection-oriented network. Given that interactive voice traffic has alternating periods of activity and silence [2][3], packet switching allows for greater bandwidth utilization than circuit switching. The connection-oriented aspect of virtual circuit networks allows for delay guarantees to be provided. The one-way delay requirement for telephony traffic is 25ms without echo cancellers, and with echo cancellers, the requirement is 150ms for excellent quality voice and 400ms for acceptable quality voice [4]. Thus, MAC protocols that support resource reservation on a virtual circuit basis are well suited for telephony traffic given its bursty nature and stringent delay requirements. In the current commercial environment of cellular and Personal Communication Services (PCS) networks, there is more interest in “wireless Internet” (i.e., in carrying data from Internet applications) than in changing the mode of carrying voice, i.e., from a circuit switched mode to a packet-switched mode. However, this latter movement is happening in “wired” networks with a growing interest in voice over IP and voice over ATM. Given that bandwidth is more constrained in wireless networks, we regard the problem of developing solutions for carrying voice over packet-switched wireless networks quite important. This work (on determining how polling schemes can be used in packet-switched wireless networks) is applicable to outdoor cellular and PCS networks when these networks transition to a packet-switched mode of operation. In the near-term, the results of this work is applicable in IEEE 802.11 LANs that support a polling mode of operation. By having in-building users use wireless LAN access for their voice calls (on the unlicensed band used in 802.11 LANs), more of the cellular resources are available 9 for outdoors users and buildings without 802.11 LANs. This will lead to a better overall wireless bandwidth utilization. Chapter 2 summarizes the operation of the 802.11 MAC protocol. Chapter 3 describes our solution for how to use a polling based wireless network to carry voice calls. Chapter 4 describes an analysis to determine optimal values of inter-poll periods, and characterizes the maximum number of voice calls that can be supported, end-to-end delays and packet loss rates. Chapter 5 describes a simulation study of an 802.11 LAN. Finally, Chapter 6 presents our conclusions. 10 2.0 IEEE 802.11 Overview The purpose of the IEEE 802.11 standard is to provide wireless connectivity to equipment or stations that require rapid deployment, which may be portable or hand-held. The IEEE 802.11 layer is required to appear to higher layers [logical link control (LLC)] as a current-style 802 LAN. This requires that the IEEE 802.11 network handle station mobility within the MAC sublayer. For this reason it is necessary for IEEE 802.11 to incorporate functionality that is untraditional for MAC sublayers. There are two access methods defined at the MAC layer: The Distributed Coordination Function (DCF) and the Point Coordination Function (PCF). The DCF operates in both adhoc and infrastructure networks where as the PCF only exists in the infrastructure network. Stations must support DCF but may or may not support PCF. The MAC sublayer uses the services of the lower layer to transfer MAC protocol data units (MPDUs) between peer MAC entities. The standard defines three physical layer implementations: frequency hoping spread spectrum (FHSS), direct sequence spread spectrum (DSSS) and infrared (IR). The FHSS and DSSS utilize the 2.4 GHz Industrial, Scientific and Medical (ISM) band and the IR a wavelength range from 850 to 950 nm. What follows is an introduction to the various components that make up an 802.11 Wireless LAN and a detailed explanation of the access methods defined at the MAC layer. 2.1 Components of the 802.11 architecture The IEEE 802.11 wireless LAN architecture consists of several components. 11 The basic service set (BSS) is the basic building block of an IEEE 802.11 LAN. Figure 2.1 shows two BSSs, each of which has two stations that are members of the BSS. BSS 1 STA 1 STA 2 BSS 2 STA 3 STA 4 Figure 2.1: Basic service sets The stations depicted in the ovals are the members of the BSS. The BSS can be thought of as the area over which the various member stations can remain in communication. The independent BSS (IBSS) is the most basic IEEE 802.11 LAN and may consist of only 2 members. The LAN (BSS) depicted above can also be used to set up an ad hoc network. In order to extend the coverage of a BSS and to facilitate inter-BSS (interconnect BSSs) communications, a Distribution System (DS) can be used. The DS enables mobile device support by providing the logical services necessary to handle address to destination mapping and seamless integration of multiple BSSs. The component that provides access to the DS is the Access Point (AP). This is shown in figure 2.2 below. 12 BSS 1 STA 1 STA 2 AP DS BSS 2 AP STA 3 STA 4 Figure 2.2: Distribution system As the diagram shows, movement of data from the BSS to the DS goes via the AP. The AP may therefore have more than one address: One for the wireless medium (WM) and the other for the distribution system medium (DSM), which are logically different media. This larger network is known as the extended service set (ESS). 2.1.1 Integration with wired LANS A logical component called a portal is used to integrate the 802.11 architecture with the wired LAN. This is the point at which packets from a non-802.11 LAN enter the 802.11 LAN. This is shown in figure 2.3 below. The portal may be part of the AP, in which case, the DS is an 802 LAN. 13 BSS 1 STA 1 STA 2 AP DS AP BSS 2 Portal STA 3 802.x LAN STA 4 Figure 2.3: Connecting to other 802 LANs The 802.11 standard specifies services that are required of the DS and the stations i.e., distribution system services (DSS) and station services (SS). A total of nine services have been defined of which six facilitate MSDU delivery and three control LAN access and confidentiality. Station services include authentication, deauthentication, privacy and MSDU delivery. Distribution system services include association, disassociation, distribution, integration and reassociation. These services are further explained below. 1) Distribution: This service is used each time a station sends data from one BSS to another via the DS. The method in which the message is delivered is not part of the standard. All that the DS provides is information sufficient enough to determine the recipient across the DS. This information is provided by the association, disassociation and reassociation services. 2) Integration: If the intended recipient is another 802 member then the DS must forward the message to the portal. The portal invokes the Integration service/function that is responsible for delivering the message to the required recipient. 14 3) Association: This provides the DS with a station to AP mapping thus enabling the DS to deliver data across the DS. The mobile stations initiate Association and a station can be associated to only one AP at any given time. Association is enough for delivery of data to stations that do not traverse between BBSs. 4) Reassociation: This function is necessary for mobility between BSSs. It enables the DS to know the current station to AP mapping. 5) Disassociation: When a station needs to terminate a current association, the disassociation function is invoked. Disassociation is a notification and not a request and therefore cannot be refused by either station. APs need to disassociate stations to enable their removal from the network. Stations disassociate whenever they move out of the network. 6) Authentication: In order to provide some level of privacy as is present in wired networks, an Authentication service has been defined. Only when stations have been able to establish an acceptable level of authentication will the association service be invoked. 7) Preauthentication: To speed up the authentication process, a previously authenticated station can first under go association and then authentication. 8) Deauthentication: This service is invoked to terminate an existing authentication. 15 2.2 MAC Services This section describes the services that the MAC layer provides to the LLC layer. 2.2.1 Asynchronous data service This services provides peer LLC entities with the ability to exchange MAC service data units (MSDUs) on a best-effort connectionless basis. There are no guarantees that the submitted MSDU will be delivered successfully. Depending on the service type selected by the LLC, the MAC entities may or may not perform MSDU reordering. 2.2.2 Security services Authentication and the wired equivalent privacy (WEP) mechanism are the security services provided by 802.11. This is limited to station-to-station data exchange. WEP is logically located in the MAC sublayer and provides encryption of the MSDU. 2.3 MAC Frame formats The basic components of a frame are a) MAC header: Comprises frame control, duration, address, and sequence control information. b) Frame body: This is a variable length field that contains information specific to the frame type. c) Frame check sequence (FCS): Contains the 32-bit cyclic redundancy check (CRC). 16 2.3.1 General frame format The figure below depicts the general frame format of a MAC frame. Frame Control Duration ID Octets 2 Address 1 2 6 Address 2 6 Address 3 Sequence Control 6 Address 4 2 6 Frame Body FCS 0-2312 4 Figure 2.4: MAC frame format The Address 2, Address 3, Sequence Control, Address 4 and Frame Body are only present in certain frame types. Below is an explanation of the various fields. 2.3.1.1 Frame control field The frame control field is shown below. Protocol Version Bits: 2 Type 2 Subtype 4 To DS 1 From DS More Frag Retry 1 1 1 Pwr Mgt More Data 1 1 WEP 1 Order 1 Figure 2.5: Frame Control Field A brief explanation of the fields follows. i) Protocol Version: Contains the version of the standard. The current standard is version 0. If a station receives a frame with a higher version than it supports the frame will be discarded without notification to the LLC layer or the sending station. ii) Type and Subtype: Together the two fields identify the function of the frame. There are three frame types: control, data and management. Each of these types has various subtypes of which a few are shown in the table below. 17 Table 2.1: Valid Type/Subtype combinations Type Value 00 00 00 00 00 01 01 01 01 01 10 10 10 10 10 10 iii) Type description Management Management Management Management Management Control Control Control Control Control Data Data Data Data Data Data Subtype value 0000 0001 0110-0111 1000 1101-1111 0000-1001 1011 1100 1101 1110 0000 0001 0010 0011 0100 0101 Subtype description Association request Association response Reserved Beacon Reserved Reserved Request To Send (RTS) Clear To Send (CTS) Acknowledgement (Ack) Contention Free (CF)-End Data Data + CF-Ack Data + CF-Poll Data + CF-Ack + CF-Ack Null Function (no data) CF-Ack (no data) To DS and From DS fields: The To DS field is set to ‘1’ in Data frames destined for the DS. The From DS field is set to ‘1’ in Data frames exiting the DS. iv) Retry field: This is set to ‘1’ in frames that are retransmissions. A receiving station can use this field to eliminate duplicate frames. v) Power Management field: The value indicates the power management mode of the station after the completion of the current frame exchange sequence. A value of ‘1’ indicates that the station will be in power-save mode and a value of ‘0’ that it will be in the active mode. vi) More Data field: This field is set to ‘1’ by an AP to indicate to a station that the AP has one or more buffered MSDUs or MAC Management PDUs (MMPDUs) for the station. It is also set to ‘1’ in directed data type frames transmitted by the contention free (CF)-pollable station to the point coordinator (PC) in response to a 18 CF-Poll to indicate that the station has at least one additional buffered MSDU available for transmission in response to a subsequent CF-Poll. vii) WEP field: This is set to ‘1’ if the frame body contains information that has been processed by the WEP algorithm. 2.3.1.2 Duration/ID field This field is used in two ways. This field usually contains a duration value (Net Allocation Vector – NAV) that is used in the medium access control algorithm such that it contains the amount of time the current transmission will be occupying the medium. In control frames of subtype PS-Poll it carries the ID of the station that transmitted the frame (the AP AID). 2.3.1.3 Address fields The four address fields are 48-bit IEEE 802 MAC addresses. The four types of addresses are the BSS identifier (BSSID), source address, destination address, receiving station address and the transmitting station address. The BSSID is the 48-bit address of the station housing the AP in a BSS or a 46-bit random number in an IBSS. The source address identifies the originator of the MSDU being transmitted. The destination address is the individual MAC address of the entity to which the MSDU is to be ultimately delivered. Receiver address is the address of the immediate recipient on the wireless medium. Transmitter address is the address of the station that transmitted onto the wireless medium. The table below explains the usage of the To DS and From DS fields in conjunction with the four address fields. 19 Table 2.2: To DS /From DS To DS 0 0 Destination Address Source Address 0 1 BSSID 1 0 Destination Address BSSID 1 1 i) From DS Address 1 Receiver Address Address 2 Address 3 BSSID Source Address Source Destination Address Address Transmitte Destination r Address Address Address 4 N/A N/A N/A Source Address Meaning Data frame from station to station within a BSS Data frame exiting the DS Data frame destined for the DS WDS frame being distributed from AP to AP To DS = 0, From DS = 0. This corresponds to the case when MSDUs do not exit the BSS, that is, the source and destination stations are within the same BSS. ii) To DS = 0, From DS = 1. This corresponds to the case when a frame if transferred from the distribution system to an individual station in the BSS. The stations within the BSS look at the address 1 field to determine if they are the recipients, the address 2 field contains the address to where the Acknowledgement (Ack) frame is to be sent (the AP) and the address 3 field contains the address of the MSDU originator. iii) To DS = 1, From DS = 0. This corresponds to the case when a station wants to transfer a frame on to the DS. All stations in the BSS look at the address 1 field to check whether the frame is intended for them (including the AP). As the frame needs to traverse the DS and the AP is responsible for facilitating this, the address 1 field contains the address of the AP. The address 2 field contains the address 20 that the Ack frame is to be addressed to. The address 3 field contains the address of the final recipient of the frame. iv) To DS = 1, From DS = 1. This case applies when the DS is a wireless DS (WDS). The address 1 field contains the receiver address in the AP of the next immediate recipient of the frame in the DS. The address 2 field contains the address to which the Ack is to be addressed. The address 3 field contains the address of the final recipient of the frame in the ESS and the address 4 field the originator of the frame. 2.3.1.4 Sequence Control field This field is further subdivided into two fields, the Sequence Number (12 bits) and the Fragment Number (4 bits) as shown in the figure below. Fragment Number Sequence Number Figure 2.6: Sequence Control field Sequence numbers are not used in Ack frames. They are present in MSDUs and MMPDUs and are used to detect duplicate frames. The fragment number is set to 0 in the first fragment and is incremented by one in every subsequent fragment. It remains constant in retransmissions of fragments. 2.3.1.5 Frame body field This is a variable length field that contains information specific to individual frame types and subtypes. The minimum frame body is zero octets. 21 2.3.1.6 FCS field This is a 32-bit field containing a 32-bit Cyclic Redundancy Check (CRC). The FCS is calculated over all the fields of the MAC header and the Frame Body field. 2.3.2 Format of Individual frame types Below we describe the frame formats for the Control, Data and Management frame types. 2.3.2.1 Control frames 2.3.2.1.1 Request To Send (RTS) frame format Frame Control Duration RA TA FCS Figure 2.7: RTS frame The RA of the RTS frame is the address of the station, on the WM, that is the intended immediate recipient of the pending directed data or management frame or RTS. The TA is the address of the station transmitting the RTS frame. The duration value is the time in ms required to transmit the pending data or management frame + one CTS frame + one Ack frame + three SIFS intervals. 22 2.3.2.1.2 Clear To Send (CTS) frame format Frame Control Duration RA FCS Figure2.8: CTS frame The RA of the CTS frame is copied from the TA field of the immediately previous RTS frame to which the CTS is a response. 2.3.2.1.3 Acknowledgement (Ack) frame format Frame Control Duration RA FCS Figure 2.9: Ack frame The RA of the Ack frame is copied from the Address 2 field of the immediately previous directed data, management or PS-Poll control frame. 2.3.2.1.4 CF-End and CF-End + CF-Ack frame format Frame Control Duration RA BSSID FCS Figure 2.10: CF-End frame The frame format for the CF-End and the CF-End + CF-Ack frame is the same. The subtype field is used for differentiating between them. This technique is known as piggybacking. The BSSID is the address of the station contained in the AP and the RA is the broadcast group address. The duration field is set to 0. 23 2.3.2.2 Data frames The frame format for a data frame is shown in figure 2.4. Data frames are independent of the frame subtype . 2.3.2.3 Management frames Frame Control Duration DA SA BSSID Sequence Control Frame Body FCS Figure 2.11: Management frame Management frames include the Beacon, the IBSS Announcement Traffic Indication Message (ATIM), the association and reassociation requests, the disassociation notification, the authentication and the deauthentication frames. 2.4 Functional description of MAC sublayer Having looked at the various types of frames and their formats we now look at the functional description of the MAC sublayer. The MAC sublayer defines two types of medium access procedures: The Distributed Coordination Function (DCF) and the Point Coordination Function (PCF). The DCF is based on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) and must be implemented by all stations. The period during which the wireless LAN operates in the DCF mode is also known as the contention period (CP). The Point Coordination Function (PCF) is operated by a logical entity called the Point Coordinator (PC) that controls access to the medium by implementing a polling scheme. Implementation of the polling scheme is not specified by the standard. The period during which the wireless LAN operates in the PCF mode is also known as the Contention Free Period (CFP). 24 2.4.1 Distributed Coordination Function (DCF) The DCF is the fundamental access method of the 802.11 MAC sublayer. The DCF provides automatic medium sharing between compatible physical media through the use of CSMA/CA and a random backoff time following a busy medium condition. Carrier sensing is performed through both physical and virtual mechanisms. Physical carrier sensing is accomplished by stations actually analyzing all detected packets on the wireless medium and by determining the channel usage via relative signal strength from other sources. Virtual carrier sensing is accomplished by distributing reservation information announcing the impending use of the medium. The Duration field in the exchange of RTS and CTS frames before transfer of actual data frames spreads the reservation information to all stations within listening distance of the station reserving the medium and the AP that acknowledges the reservation. The reservation time includes the time to transmit the data frame as well the time for the returning Ack frame. On listening to the RTS/CTS transmission all stations assign the value in the duration field to a local parameter, the Network Allocation Vector (NAV). This indicates the amount of time that must elapse until the current transmission is complete and the station can sample the medium for idle status. If the RTS/CTS frames are not utilized to reserve the medium, directed data frames also have the duration field that provides the same information. As long as the NAV is non-zero or the channel is determined to be in use the status of the channel is marked busy. The RTS/CTS frame transfer has a number of advantages: 25 1) The exchange is useful in cases where a station may not hear the transmissions of other stations but can hear transmissions from the AP (a hidden terminal). Thus, the hidden terminal will learn about the impending frame transfer. 2) If the station transmitting the RTS does not hear the returning CTS, it can repeat the process faster (after observing the medium access rules) in contrast to when it transmits a large data frame and does not hear the Ack. The exchange of RTS/CTS in a wireless LAN that is heavily loaded is beneficial because if collisions occur they are quickly detected as the frames are short. If a data frame experiences collisions, the whole frame must complete transmission, since the station transmitting cannot sense the medium. This wastes bandwidth. On the other hand, if the wireless LAN is lightly loaded, the RTS/CTS exchange adds additional delay. By making the RTS/CTS handshake dependent on the size of the MAC frame being transmitted, the exchange of the RTS/CTS frames can be controlled. If the size of the frame is less than the manageable parameter dot11RTSThreshold the station transmits a directed data frame (after having determined the medium to be idle) without first transmitting the RTS. If the frame is larger than dot11RTSThreshold the data frame is transmitted after successful reception of the CTS frame. Certain frames require acknowledgements. Receiving stations responds with the Ack frame if the FCS/CRC of the received frame is correct. If not, receiving stations do not reply. If a transmitting station does not receive an acknowledgement frame it assumes that the frame was errored and after a random backoff procedure will re-contend for the medium and transmit the frame. This mechanism is known as positive acknowledgement. 26 Access to the wireless media is prioritized by the use of interframe spaces (IFS), which are the time periods between frames. All stations must therefore remain quiet for a certain minimum period (the IFS) after a transmission has been completed. The four IFS are: a) SIFS (short interframe space) b) PIFS (PCF interframe space) c) DIFS (DCF interframe space) d) EIFS (extended interframe space) The SIFS is the shortest interval and the EIFS the longest. Stations required to wait a SIFS interval have the highest access priority in accessing the media where as those stations required to wait an EIFS have the lowest access priority to the wireless media. The SIFS is used for the Ack frame, the CTS frame, the subsequent fragment of an MPDU, stations responding to any of the Poll frames during the CFP and by the PC for sending the CF-End frame. The PIFS is used only by stations operating under the PCF to gain priority access to the medium at the start of the CFP. A station using the PCF is allowed to transmit contention-free traffic after its carrier sense mechanism determines that the medium is idle. The AP (a.k.a. Point Coordiantor) is therefore required to wait only a PIFS interval before gaining control of the medium in order to initiate the CFP. The AP also waits a PIFS if during the CFP it does not receive a response to a Poll frame. This ensures that it always has control of the medium. 27 The DIFS is be used by stations operating under the DCF to transmit data frames (MPDUs) and management frames (MMPDUs). A station using the DCF is allowed to transmit if its carrier sense mechanism determines that the medium is idle and its backoff time has expired. If the station determines the channel to be busy it calculates a Random Backoff Time to schedule a reattempt. The EIFS is used by the DCF whenever the physical sublayer has indicated to the MAC that a frame transmission was begun that did not result in the correct reception of a complete MAC frame with a correct FCS value. The EIFS interval begins following indication by the physical sublayer that the medium is idle after detection of the erroneous frame, without regard to the virtual carrier-sense mechanism. Figure 2.12 shows the transmissions of MPDUs without the use of RTS/CTS handshake and figure 2.13 shows the frame transfer using the RTS/CTS frames. Both show the value of the NAV and the various IFSs. DIFS DATA SOURCE SIFS Ack DESTINATION DIFS OTHER NAV Defer Access Wait for Reattempt Time Figure 2.12: Transmission of MPDU without RTS/CTS 28 DIFS RTS DATA SOURCE SIFS CTS SIFS SIFS Ack DESTINATION DIFS NAV (RTS) OTHER NAV (CTS) NAV (DATA) Defer Access Wait for Reattempt Time Figure 2.13: Transmission of MPDU using RTS/CTS Stations maintain counters that are incremented each time a frame is retransmitted. Two different counters are implemented, the station short retry count (SSRC) and the station long retry count (SLRC). There are also counters associated with the MSDUs and MPDUs, i.e., the short retry count and the long retry count. Retransmissions of MAC frames shorter than or equal to the management parameter dot11RTSThreshold cause the short retry counter associated with that particular MSDU/MPDU to be incremented and MAC frames larger than the dot11RTSThreshold cause the long retry counter associated with that particular MSDU/MPDU to be incremented. The SSRC or the SLRC are incremented each time a packet is retransmitted. If the frames are successfully transmitted all counters are reset. These retransmissions will continue until the short retry counter and the long retry counter equal the dot11ShortRetryLimit and the dot11LongRetryLimit respectively. The MAC frame 29 will then be discarded. The values of the dot11ShortRetryLimit and the dot11LongRetryLimit range from 1 – 255. When the LLC passes a frame down to the MAC entity, the MAC sublayer determines whether the frame needs to be fragmented or not. If the size of the MSDU or MMPDU is greater than the settable MIB variable aFragamentationTheshold the frame will be fragmented. If fragmentation occurs, the station will reserve the channel for as long as it takes to transmit all the fragments belonging to that MSDU or MMPDU. 2.4.2 Point Coordination Function (PCF) The PCF is an optional capability, which can be used to provide connectionoriented, contention-free services by enabling polled stations to transmit without contending for the channel. The CFP is under the control of a point coordinator that typically resides in the AP. Stations within the BSS that are capable of operating in the CFP are termed as CF-Aware stations. The PCF and DCF are required to coexist. The PCF logically sits on top of the DCF and actually uses the DCF medium access techniques. The CFP alternates with the CP during which the DCF controls frame transfers. At the start of the CFP the AP transmits the Beacon frame that contains the CF parameter set, which contains a set of parameters required to support the PCF. These are: i) CFPPeriod: This is the reciprocal of the rate at which the AP initiates the CFP. This lets the stations know when the AP will try to initiate the CFP again. 30 ii) CFPMaxDuration: This indicates the maximum duration of the CFP that may be generated by this PCF. This value is used by stations to set their NAV at the beginning of CFPs. iii) CFPDurRemaining: This indicates the maximum time remaining in the present CFP, and is set to zero in CFP Parameter element of beacons transmitted during the contention period. This value is used by all stations to update their NAVs during CFPs. This is especially useful to stations that were asleep when the initial Beacon was transmitted and awakened during the CFP. Figure 2.14 shows the typical frame transfer during the CFP. Contention Free Repetition Interval (CFPRate) Contention Free Period SIFS Beacon D2+ack +poll D1+poll CF-End U1+ack PIFS Contention Period SIFS SIFS SIFS U2+ack SIFS Reset NAV NAV CFPMaxDuration Figure 2.14: Point Coordination Frame Transfer The AP then takes control of the medium by transmitting the initial Beacon control frame. All stations except the AP set their NAV to the CFPMaxDuration value contained in the Beacon CFP parameter set. This ensures that the AP has control of the medium for the duration of the CFP. The AP then starts polling the stations on its polling list. The mechanism of placing stations on the polling list is implementation dependent. 31 During the CFP various frames can be “piggybacked”. This is shown in figure 14. Piggybacking is facilitated by the use of the subtype field in the MAC header. Interestingly, an acknowledgement does not need to be directed to the station expecting the acknowledgement. A frame can an acknowledge a previous frame even if not directed to that previous frame. That is, if station A transmits a frame requiring an Ack to the AP, the frame of subtype Poll + Ack directed to station B from the AP, acknowledges the receipt of the frame from station A to station A. Station A looks at the subtype field and determines whether the frame contains an Ack component. The RTS/CTS exchange is not used during the CFP. All CF-Pollable stations (stations that can respond to a Poll) respond to the Poll frame from the AP within a SIFS. If the station has nothing to send it send the Null frame (data field of 0 bytes). If the AP does not receive a response from the station it waits a PIFS and can either retransmit the frame or poll the next station on the polling list. Depending on the implementation, the AP may retransmit the frame when the station is once again at the top of the polling list. As the CFP and the CP alternate the sum of the two periods is called the “superframe”. This is depicted in figure 2.15. As shown in the figure, it may happen that a station begins to transmit a frame just before the end of the CP, hence elongating the current superframe and shortening the next CFP. This is known as stretching. The worst case occurs when the frame has a payload of 2304 and the aFragmentationThreshold is set to a much lower value. Stretching eats into the CFP as the standard states that the CP cannot be altered. 32 Elongated CP superframe superframe CFP CP CFP CP Foreshortened CFP Figure 2.15: Stretching If the traffic during the CFP is light and/or the AP has completed polling all the stations on the polling list, it can end the CFP by transmitting a CF-End frame. This is depicted in figure 14, where the CF-End frame is sent before CFPMaxDuration is reached. 33 3.0 Proposed method for carrying interactive voice in 802.11 LANs The main focus of this work is to determine whether the PCF mode of the 802.11 WLAN is suitable for carrying interactive voice. Before delving into this issue, a brief discussion of the different types of traffic and the appropriate networks for carrying these traffic types follows. 3.1 Types of applications and networks suited to serving them There are many different applications in use today e.g., telnet, ftp, http, real audio etc. Most applications can be classified into two main categories: Real-time and non-realtime applications, as depicted in table 3.1 below. Table 3.1: Categorization of applications Sending end Consuming end Live Stored Live Interactive/Streaming Recording Stored Streaming Non-real-time 3.1.1 Real-time applications and networks suited to serving them: In real-time applications either the sender sends data that is generated “live” or the receiver consumes the data “live”. Real-time applications can be further subdivided into two-way interactive sessions (telephony), streaming applications where the media is stored at the sender’s end and consumed live by the receiver e.g., stored audio, streaming and recording applications where the media is sent live but stored at the receiver’s end e.g., using a video recorder to record a game televised live). Examples other real-time applications are telnet, ftp, http etc. Such traffic is generally bursty and these applications 34 have strict requirements on jitter and end-to-end delay. Loss is typically tolerable because codecs can deal with packet loss (an exception is compressed video that places strict demands on loss as well). In order to serve applications with constrained delay and jitter bounds a connection-oriented mode of networking is most efficient [24]. Bursty traffic is best served by packet switching. Thus, networks best suited for real-time applications are packet-switched connection-oriented. 3.1.2 Non-real-time applications and networks suited to serving them: In non-real-time applications data is sent from a “stored” file and is stored at the receiver’s end. Examples of such applications are file transfers and electronic mail. The received data is not consumed “live” but stored for later use. The traffic is generally less bursty because the data can be sent in continuous mode. It is also characterized by long data transfers. These applications place strict demands on loss but typically have lax delay and jitter requirements. Applications that do not have delay or jitter constraints can best be served by connectionless networking modes. For large file transfers, circuit switching has been shown to be preferable [24]. Thus, for non-real-time applications involving long file transfers, networks that are circuit switched (and inherently connection-oriented) are suitable. As noted earlier, one of the modes of operation of the IEEE 802.11 WLAN, the PCF, was designed for real-time applications and offers a packet-switched connectionoriented service. As was explained above, packet-switched connection-oriented services 35 are prefered for real-time applications. Therefore, the main focus of this work is to determine how to use the PCF mode to carry interactive voice traffic. The solution is based on a number of design choices that span the following areas: i) Network architecture ii) Different types of polling schemes iii) User plane actions. How are voice packets carried on the WLAN? iv) Control plane actions. How do we admit calls? 3.2 Design choices The analysis (carried out and presented in a later section) is almost entirely dependent on the design of the network. The following sections discuss the various design issues, for example, network architecture, voice protocol stack, timing method used for voice packet reconstruction, etc and our solutions. 3.2.1 Network Architecture The network architecture is dependent on the type of voice calls that are envisioned for the WLAN, i.e., are calls only expected to take place between 802.11 endpoints or also between 802.11 endpoints and PSTN phones, IP phones or ATM endpoints. In order to communicate with non-802.11 endpoints a gateway is needed to perform the relevant protocol conversions of voice as well as and signaling protocols. The architecture is shown in figure 3.1. 36 Voice Gateway AP PSTN ATM Network AP Internet Ethernet 802.11 End host 802.11 End host Figure 3.1: Proposed architecture The voice gateway has an 802.11 interface, which enables the AP to communicate with it over the wireless medium. All voice calls will go through the AP. The AP will admit calls based on the resources available and those requested by a callee. If the AP is able to service the call as requested it admits the call, if not, it rejects it. This would ensure that on the WLAN calls are serviced at the requested QoS parameters. End-to-end delays can be guaranteed even between the WLAN and the PSTN and/or an ATM network as they are connection-oriented. 3.2.1.1 Voice gateway Interfaces supported by the voice gateway include: i) PSTN interface: At this interface the gateway converts the 802.11 voice protocol stack to PCM voice supported by the PSTN and vice versa. ii) ATM interface: At this interface, the gateway converts between the 802.11 voice stack and voice over an ATM adaptation layer, such as AAL2. 37 iii) Ethernet interface: At this interface, the gateway converts between the 802.11 voice stack and voice over Real-time Transport Protocol (RTP)/UDP/IP. A signaling component (signaling gateway) must also be present to enable call setup/tear down over the different networks. The signaling gateway may be co-located with the voice gateway or it may be a separate entity. In the above discussion, we referred to an 802.11 voice protocol stack. This will be defined in a later section. 3.2.2 Polling Schemes As earlier mentioned, 802.11 does not specify the process by which stations place themselves on the polling list. Creation of the polling list and call admission depends on the signaling scheme, which is described in Section 3.2.4. Placing call ends on the polling list depends on the polling scheme implemented. Examples of two schemes are as follows. The first scheme keeps adding the two ends of calls to the polling list as calls arrive. In this option, packets from the two directions of the call will experience very different delays. If a call, say A, has two ends A1 and A2, and A1 is placed on the polling list immediately followed by A2, then the A1 to A2 packets experience short delays because on the A2 poll, data received from A1 can be delivered immediately. However A2 to A1 packets will experience a delay close to that of the superframe size. This is illustrated in figure 3.2 below. 38 Access Point A1 Poll + A1 Data Poll + B2 Data Poll + B1 Data Poll + A2 Data A2 B1 B2 A1 Figure 3.2: Polling list formation – scheme 1 In the second scheme, if one end is placed in the first half of the polling list, the second end is placed at an “equidistant” point in the second half of the polling list. This decreases the delay difference in the two directions but because of the presence of the CP, but it does not ensure equal delays for the two directions. This is shown in figure 3.3 below. Access Point A1 Poll + B2 Data Poll + A1 Data Poll + B1 Data Poll + A2 Data B1 A2 B2 A1 Figure 3.3: Polling list formation – scheme 2 The drawback of this scheme is that the jitter increases because as new calls are added the delay in the A1 – A2 direction increases because the K1 ends of theses new calls are placed before the A2 end of the first call. For this work we assumed that the polling scheme implemented scheme 1. 39 3.2.3 User-plane actions This section presents the issues that need to be addressed in order to carry voice packets in wireless MAC frames and our solutions. We consider two modes of operation for carrying voice: i) The Constant Bit Rate (CBR) mode, in which calls are allocated their peak rate, i.e., as if the sender is always in a talk spurt, and silences are not exploited for other voice calls or data traffic. ii) The Variable Bit Rate (VBR) mode, in which statistical multiplexing is used and silence in a voice call is used by other voice calls or data traffic. This work considers both modes presents our analysis for both. User plane issues that need to be addressed include: i) Whether the packet size should be fixed or variable in length. ii) The timing method (for packet reconstruction at the receiving end), whether Complete Timing Information (CTI) or Null Timing Information (NTI). iii) The protocol stack used to carry voice. iv) The frequency with which the AP polls various stations. v) When Contention Periods and Contention Free Periods should be terminated. vi) Whether error correction is needed or not. 3.2.3.1 Whether the packet size should be fixed or variable in length Voice codecs typically produce a given number of bytes every few msec (for example, the Truespeech codec produces 32 bytes every 30ms). It therefore follows that 40 the station could generate separate 802.11 MAC frames for each voice packet generated by the codec, suggesting that packet sizes are fixed. However, the overhead of protocol layers can be significant (e.g., with 802.11, just the MAC layer header is 34 bytes). Hence we recommend sending all the voice data generated within an interpoll period in one packet. In both modes of operation, CBR and VBR, variable length packets will be created. 3.2.3.2 Timing method The two choices are Complete Timing Information (CTI) and Null Timing Information (NTI) [19][20]. CTI is used in Real-time Transport ProtocolRTP [21], which uses a relative time-stamping method that works well in networks where variable length packets are used and delay variability is high for real-time traffic. The method used in ATM networks to carry voice over AAL2 [22] is NTI. In NTI schemes, each packet does not carry a time indication. Instead if the end-to-end jitter is known, the first packet of a talk spurt can be delayed by a build-out delay value equal to the jitter (just in case the first packet arrived with the minimum delay) and then subsequent packets are played out with inter-playout times equal to the packetization intervals. Since ATM cells are fixed size, the packetization delay is fixed and hence even if subsequent cells within a talk spurt experience different delays from the first packet, by playing them out in intervals of T, the packetization delay, the exact sent sequence is reconstructed. So a combination of ATM networks being connection-oriented, which allows for a determination of jitter, and ATM using fixed cell sizes, allows for the use of NTI [22]. In wireless MAC protocols, if the CBR mode is used with the polling scheme, jitter may be known, but the size of 41 packets is not fixed. Also, given that the exact inter-poll period depends upon whether or not a stretching occurs of the random-access period (such as the CP in 802.11), the assumption of a constant inter-packet generation time cannot be made, and hence NTI cannot be used. Therefore, we recommend the use of a CTI scheme. Since most of the calls starting at wireless users can be expected to go outside the LAN, we assume that all voice packets are sent through the AP even though in some cases, when both ends are within the coverage area of an AP, voice packets could be sent directly between the ends. In 802.11 networks, during the PCF mode, an AP controls who sends data, but the data could be sent directly between end user stations. 3.2.3.3 Protocol Stack Given that delay requirements limit the size of voice packets, we try to avoid as much of the protocol layer overhead as possible. With this goal, we recommend running voice over RTP (given the choice of CTI timing) over the wireless LLC/MAC protocol. For example, with 802.11, between the wireless user and the voice gateway shown in figure 16, the protocol stack could be voice over RTP over LLC/802.11 MAC/802.11 PHY. The typical RTP stack calls for UDP/IP between RTP and the link layer protocols. However, these layers are not needed for the wireless portion. The RTP specification [21] states that while UDP/IP is typically used, other lower layer protocols can also be used. 3.2.3.4 Polling frequency How often should the AP poll stations on the polling list in a superframe? The AP could traverse its polling list partially per superframe (e.g., poll each node once every 42 other superframe), once per superframe, or multiple times per superframe. In the CBR mode, the AP polls nodes once per superframe. We analyzed the option of making the superframe small and polling users once every other superframe in an 802.11 context, but this just added superfame overhead (such as frames indicating the start and end of polling periods), and hence resulted in poorer overall performance. The option of polling multiple times in one large superframe can be used to offer differential delays to different calls. Varying delay requirements for the wireless portion arise because the “wired” ends of calls could be PSTN phones, ATM phones or IP phones. Calls to ATM/IP phones as shown in figure 16 will require shorter delays on the wireless portion than calls to PSTN phones or intra-AP calls. For the VBR mode, since not all calls may get polled in a superframe (given that we admit more calls than in CBR mode), the polling cycle is simply continued from superframe to super-frame. 3.2.3.5 Termination of the Contention and Contention Free Periods In the CBR mode, given that each voice call is allocated its peak duration irrespective of the size of the packet, the length of the random-access period will be determined by the number of voice calls admitted. In the VBR mode, when the AP completes polling all stations in the polling list, it sends a frame to terminate the polling period, and starts the random-access period, even if the maximum duration allocated to the polling period is not exhausted (this may occur if several voice users are silent). However, it leaves the medium idle during the random-access period, even if there are no data users. This choice is made to keep data throughput at acceptable levels. 43 For the CBR mode, the superframe length is fixed. The maximum number of calls that an be admitted is determined by the superframe length. Varying the superframe length would impact delay variations of admitted calls, and hence this is avoided. Interestingly, it is possible to change the superframe length in wireless networks in which the beacon carries parameters indicating the superframe length as in 802.11. 3.2.3.6 Whether error correction is needed or not Our error analysis for voice in Section IV shows that some form of error correction is needed. There are three options. First, forward error correction (FEC) could be used to correct errors. Second, retransmission could be used. In the downstream direction, the AP should resend any packet for which it experiences an ACKTimeout. In the upstream direction, given our assumption that all voice packets are routed through the AP, the AP will time out waiting for a response to its poll, or notice that a received packet is errored, leading it to poll the source mobile station again for a retransmission of the packet. This means that the CAC algorithm should allocate fewer voice calls than the maximum possible if no errors occurred. Delay should be considered carefully when allowing for retransmissions. A third option is to deliver errored packets to the signal processor, and have it reconstruct the voice signals. 44 3.2.4 Control plane actions This section addresses the following issues: i) Signaling protocol and associated Connection Admission Control (CAC) procedure. ii) Determination of the maximum number of voice calls that the WLAN is able to support. Signaling protocols are used for call establishment/setup and tear-down . For this work a signaling protocol with an associated CAC procedure is proposed to ensure that not too many voice calls are admitted to the polling list. When a mobile user initiates a voice application, a signaling message is sent to the AP requesting to be added to the polling list. The AP maintains the number of voice calls admitted to be less than a maximum count, the determination of which is explained below. The AP then sends a signaling message to the called mobile station (for intra-AP calls) or voice gateway (for PSTN/ATM/IP calls) specifying the reconstruction delay for received voice packets. On acceptance of the voice call by the called party/voice gateway, indicated by a response to the AP, the AP places the two wireless ends of the voice call on its polling list, and sends a response to the calling end along with a reconstruction delay for this end to use for voice packets it receives from the other end. When a voice call terminates, i.e., when the AP receives a release message, it drops both ends from its polling list. The computation of the maximum number of calls and reconstruction delays is dependent on the exact MAC protocol used. Hence, we only demonstrate how these 45 numbers are computed using the IEEE 802.11 MAC protocol. Table 3.2 lists our notation. Table 3.2: Parameters Parameter Maximum duration of the superframe (includes stretching period) Beacon interval in sec Symbol TSF Values as assumed for numerical evaluation Varies Tb c R Varies h 57 x 8 P Np 16 x 8 and 24 x 8 Computed Ns Computed TSF min Computed Tcp min Computed Tcfp min Computed 2304 x 8 Fragment threshold size (payload) in bits Beacon size in bits CF-end size in bits S max SDU f B CFend The SIFS interval Tsifs 0.028 ms A slot time Tslot 0.050 ms Packetization delay to create one minimum sized “sample” Time to send a voice packet generated over a superframe duration Pmin 30 ms Tv Computed Time to send an RTS (20 bytes) Trts Computed Time to send a CTS (14 bytes) Tcts Computed Time to send an acknowledgment frame without data (14 bytes) Tack Computed Voice coding rate in Kbits/sec Transmission rate in Mbits/sec 2 (FH a ) and 11 (DS) Header overheads (all layers except physical layer) in bits Physical layer header size in bits Maximum number of voice calls in the CBR mode of operation Maximum number of voice calls in the VBR mode of operation Minimum value of the super frame size Minimum value of the CP (Contention Period) - random-access Minimum value of the CFP (Contention-Free Period) - polling Maximum size of an MSDU in bits 8.5 2 (FH) and 11 (DS) 1100 x 8 and 2304 x 8 40 x 8 4x8 46 3.2.4.1 Computation of the maximum number of voice calls The maximum number of voice calls are computed for the two modes of operation, CBR and VBR. In the CBR mode, to determine how much time to allocate per call, we need to determine the maximum size of voice packets. The maximum interpoll time in this mode is TSF seconds. Add to this Pmin to capture the possibility that a voice packetization completes just after a poll. Thus, the largest voice packet size created will be c( Pmin TSF ) bits long. Given that in CBR mode, this time is allocated to each voice call whether or not it generates a packet, the time to handle a voice call (in two directions) is: Tv (c ( Pmin TSF ) h P) 4 4Tsifs R (1) To determine the maximum number of calls, we need to find the minimum duration of the CP, and then use TSF minus this minimum duration for the CFP. Tcp min includes the time to minimally send one frame as specified by [1]. Besides this minimum time, we need to allow for the possibility of stretching. Tcp _ strech is the time needed for a maximum size stretch. After the Request-To-Send/Confirm-To-Send (RTS-CTS) exchange with corresponding SIFSs, a maximum size SDU is transmitted in the stretch period as a continuous stream of fragments, without errors or need to backoff. As noted in Section 2.4.2, all fragments and ACKs are sent with only SIFS intervals between them. Each fragment is acknowledged. Tmax is the time to send a 47 maximum-sized SDU that is fragmented into fragments of size f . To accommodate the maximum number of calls, Tcp Tcp min Tcp _ strech , where (2) Tcp min 2Tsifs 2Tslot 8Tack Tmax (3) Tcp _ strech Trts Tsifs Tcts Tsifs Tmax (4) f h P Tmax (m 1) Tack 2Tsifs Tlast R (5) S where, m max SDU and Tlast is given by: f Tlast S max SDU f (m 1) h P Tack 2Tsifs R (6) To compute the maximum number of voice calls that can be admitted, we divide the time left over for the CFP after allowing for a “stretched” CP and the overhead for beacons and CF-end signals by the time required for one voice call Tv given by (1). In the case of a stretched CP, the CFP is foreshortened and hence the number of beacons is (TSF Tcp ) Tb . Thus, the maximum number of calls that can be admitted using the CBR mode is Np TSF Tcp Tovhd Tv , where (7) 48 BP TSF Tcp CFend P Tovhd Tsifs R R Tb (8) For the VBR mode of operation, we compute the maximum number of calls for two voice models: Brady’s model [2] and May and Zebo’s [3]. Both of these models are ON-OFF Markov-Modulated Fluid (MMF) models, where in the ON state data is generated at the voice codec rate. The two models differ in the mean holding times of the two states as shown in Table 3.3. By admitting more calls than N p , we are Table 3.3: Voice Models Model Mean ON period (ms) Mean OFF period (ms) p Brady’s model [2] May and Zebo [3] 1000 352 1350 650 0.43 0.35 statistically guaranteeing that loss will be less than some number . N s is given by 1 2 pN s 2N (k 2 N p ) s p k (1 p) 2 N s k k 2 N p 1 k 2 Ns (9) where p is the probability that a sending end is active. Equation (9) is based on the assumption that if a voice call is not polled in one superframe it is better to drop the packet rather than transmit it on the next superframe due to delay considerations. 3.2.4.2 Computation of build-out delay As described in Section 3.2.3.2, we selected the CTI scheme for timing, and RTP for transport. RTP uses relative timestamps. A receiver uses a build-out delay when it 49 reconstructs the voice signal. The build-out delay should be as small as possible. We first determine that the build-out delay should be the maximum possible delay difference between two packets. For example, assume the first packet took d1 seconds (which is unknown) and the total delay d from the start of packetization to delivery at the receiver Packets sent d1 d1 + y Packets received h h-y Packets played out Figure 3.4: Build-out delay is within the range d min d d max . How long should this first packet be held at the receiver before playout? Let’s say this is as shown in figure 3.4. Thus the total delay experienced by the first packet is d1 h . If the second packet took d1 y seconds (where y is known through the relative timestamp), then this packet should be delayed by h y seconds so that it experiences the same total delay as the first packet. h y 0 , which means the smallest value of h is equal to the maximum value of y . The maximum value y is d max d min , and hence the build-out delay is set to the jitter. Even if y 0 , this result holds. In this section, we determine jitter for voice packets in our solution. 50 To determine jitter, we need to identify how the two wireless ends of a voice call are placed on the polling list. The simplest scheme is to have the AP add the two ends to the polling list in sequence as calls arrive. For example, if a call, say A, has two ends A1 and A2, A1 is placed on the polling list immediately followed by A2. The A1 to A2 packets experience short delays because on the A2 poll, data received from A1 can be delivered immediately. However the A2 to A1 packets will experience a greater delay. We tried alternative polling arrangements, where the “1” ends of calls are placed in sequence followed by the “2” ends. In other words, instead of A1, A2, B1, B2, ..., we place voice call ends as A1, B1, C1, ... A2, B2, C2, .... This latter method evens the delay in the two directions, but as calls terminate, delay variation is greater because delay depends upon the position of the call in the polling list and the length of the list. In the CBR mode, all calls will have the same delay. We compute the delay for the k th call in the two directions k1 k 2 and k 2 k1assuming that the k1 end is placed on the polling list before the k 2 end. Pmin Tv T Dk1k 2 Pmin TSF v 2 2 (10) The best case is that a short packet is created in time Pmin and packetization completes just before a poll arrives. Given the CBR mode of operation, even if the packet is short, the transmission time allocated per poll and response is Tv 2 , where Tv is given by (1). Propagation delays are neglected since the radio link is short. 51 The upper bound is determined by assuming that a poll just misses the creation of a voice packet ( Pmin ). The k1 end then waits TSF for a poll (this includes the stretching period). On the next poll, when the k1 end sends the packet, it is delivered immediately to the k 2 end. The transmission time is Tv 2 . In the opposite direction, k 2 k1, the delay will be larger. This delay is bounded by Pmin TSF Tcp _ strech Dk 2k1 Pmin 2TSF (11) The lower bound is again determined assuming a small packetization delay. Further, in the best case, there will be no stretching period; in which case, the interpoll time for the k 2 end is TSF Tcp _ strech . The k1 end gets polled Tv 2 sooner than the k 2 end on the second poll. This means the time from when the k 2 end is polled to when the k1 end is polled is TSF Tcp _ strech Tv 2 . The transmission time adds Tv 2 . The upper bound occurs when a poll just misses a packetization ( Pmin ). This is followed by a wait of TSF for the next k 2 poll. This data then waits another TSF Tv 2 time to be delivered to the k1 end on the next superframe. The transmission time is Tv 2 . Given the jitter values (maximum delay - minimum delay) for the two directions of the voice call, the receiving end in each case can be provided a reconstruction delay by the AP. Thus maximum total delays for the two directions are: (12) (13) max max min TDkmax 1 k 2 Dk 1 k 2 Dk 1 k 2 Dk 1 k 2 and max max min TDkmax 2 k 1 D k 2 k 1 Dk 2 k 1 D k 2 k 1 52 where the “max” numbers are the upper bounds of (10) and (11), respectively and the “min” numbers are the lower bounds of the same equations. As calls depart, a call originally scheduled at polling position k can be moved up in the polling list to consolidate all voice calls to the head of the CFP. This would increase the amount of time available for the CP. Build-out delays used by the receiver during the transition will need to be managed by signaling. For the VBR mode of operation, delay computation is a lot more complex since if a voice call is silent, some other voice call or data packet can take advantage of the silence. This makes the interpoll period highly variable with a possibility of being larger than TSF (unlike in the CBR case, where the interpoll period is a maximum of TSF ). Additionally, delay depends upon the position of the call in the polling list. Access Point poll CFP ends A1 A2 B1 B2 K1 K2 A1 Voice call ends A2 B1 B2 K1 K2 time Voice call ends TSF TSF empty frame frame with voice data Figure 3.5: For computation of maximum delay of kth call for k1 to k2 direction For this delay analysis, we make a simplifying assumption that the same number of calls are admitted to the polling list as in the CBR mode; thus effectively, loss is 0. The goal of this analysis is to analyze the effect on delay and delay variability that arises by 53 using a VBR mode of operation in which a node releases its timeslot in case it has no voice data to send or sends a packet smaller than the maximum allocation. If a network were to be operated in this mode, while more voice calls are not accommodated, the resources saved in the polling period will result a larger contention period for data services. Incorporation of loss in the VBR mode is delegated to the simulation study in Section 5.0. Delay experienced by packets in the VBR mode in the k1 k 2 direction for the k th call in the polling list is given by Pmin cPmin DkVBR 1k 2 Pmin Tint erpoll c( Pmin T SF ) (14) Tint erpoll TSF 2(k 1)(T poll Tsifs Tnull Tsifs ) c( Pmin TSF ) (k 1) T poll Tsifs c( Pmin TSF ) 2 (15) where p is the time to transmit a packet of payload size p from the polled end to the AP and from the AP to the receiving end. Pmin is the time to create the smallest sized packet (30 ms for the Truespeech codec). That is, if Pmin is 30 ms then the packet size is cPmin bytes plus the additional headers and pre-amble bytes (that are transmitted at the 1 Mbps rate and not at the data rate of the wireless network) since c is codec rate. This minimum delay in the K1 to K2 direction is independent of the position of the call on the polling list. When (13) is compared to (10) for the CBR mode, the difference is in the packet transmission time. In CBR, even if only a small packet of payload size cPmin 54 needs to be sent, the entire timeslot reserved for the end, which is the time to transmit a packet with payload size c( Pmin TSF ) , is used. In VBR mode, transmission time incurred is only to transmit the small packet. The maximum delay shown in (13) is for the k th call on the polling list. It is determined using figure 3.5. Assume that the K1 end of the k th call just misses its poll. The first Pmin term is explained by this miss. Then, it waits to be polled again. This interpoll time is characterized in (14). To make this as large as possible (since this is a maximum delay computation), we assume that in the first superframe, all (k 1) calls preceeding the k th call are idle as shown by the dashed lines in figure 3.5. This accounts for the first line of (14). In the second superframe, we assume all the K1 ends of the first (k 1) calls are busy sending maximum-length voice frames, but these ends only receive empty polls because in the previous superframe, all K2 ends were silent. The K2 ends of the first (k 1) calls are also assumed to send maximum-length voice frames. But since these frames are only sent and not delivered, the term is halved. If the interpoll time is counted from when the K1 end receives a poll in the first superframe to when it receives a poll in the second superframe, a term T poll Tsifs needs to be added to the negative term in the first line of (14), and again in the positive term of the second line of (14). Since these cancel out, they have not been listed. The last term in (13) is the transmission time of the maximum-sized frame. We explain the assumption that the maximum-length voice frame is always c( Pmin TSF ) as follows. Each call experiences a progressively increasing inter-poll delay; the first call’s interpoll delay is TSF , but each subsequent call experiences an 55 increasing interpoll delay, until the last call, which experiences an interpoll delay of say TSF . If is larger than 30ms (the codec packet payload creation interval), then our above assumption regarding the size of maximum-length voice frames would be incorrect. However, quantitative numbers show that this is not larger than 30ms. Thus, the maximum length for voice frames assumed in (14) holds for all calls in the polling list. Consider a quantitative example for the 11 Mbps 802.11 LAN with a superframe size of 60 ms. Increasing interpoll periods are caused by a difference in length between voice frames and empty frames. The header size is 81 bytes (for the 11 Mbps LAN), while at a 60ms TSF , the maximum-sized voice packet is only 96 bytes. The header is transmitted at 1Mbps, unlike the payload, which is sent at 11Mbps. The header takes 648 s, while the payload only takes 70 s. Even if each call is delayed an extra 70 s in each direction, it does not add up to 30ms for the range of number of calls under consideration. Hence, an extra payload is not generated with increasing interpoll delays. In the k 2 k1 direction, the minimum delay is dependent on the position of the call on the polling list unlike in the k1 k 2 direction. The minimum delay experienced by the k th call on the polling list is characterized as: DkVBR 2 k 1 Pmin cPmin 2 cPmin TSF 3 cPmin TSF TSF Tcp _ strech k 1 cPmin TSF T T null sifs 2 2 cPmin 2k 1T poll Tsifs Tnull Tsifs 2 (16) 56 For the minimum delay computation, assume that the K2 end of the k th call just completes making a minimum-sized packet when it gets polled. It transmits this in cPmin 2 time. The next line in (15) has terms expressing the condition when the time left in the superframe after the K1 end of the k th call is polled as being minimal. This happens when for the first k 1 calls, a maximum-sized voice frame is delivered to the K1 ends of these calls and the K1 ends send a maximum-sized voice frame to their K2 ends. The K2 ends are assumed to be silent so that on the next superframe, the time to deliver the packet to the K1 end of the k th call is minimized. The last term 3 cPmin TSF 2 on the second line of (15) represents the delivery of a maximum-sized packet to the K1 end of the k th call, and the K1 end sending a similar packet to its K2 end. The last line of (15) models the case when all k 1 calls (both ends) are silent, and adds in the delivery time of the voice frame in question to the K1 end of the k thcall. The maximum worst case delay that calls experience for the k 2 k1 direction occurs if the K2 end of the kth call completes creating a packet immediately after it responds with a null frame in a superframe, and then continues to create a larger packet (assuming that it is still in a talkspurt) until it is polled again in the next superframe (second superframe), where it transmits its packet to the AP. The AP cannot deliver the packet to the K1 end immediately because the K1 end was already polled. It therefore delivers the packet in the third superframe. Thus, the call experiences a delay close to 3TSF . The maximum delay for the kth call polled is characterized as: 57 DkVBR 2k 1 Pmin TSF T poll Tnull 2Tsifs 2k 1 1 T poll Tsifs TSF 1 2k 1 cPmin TSF f 2 (17) Pmin is the time to create a minimum-sized packet. We assume that the K2 end just missed a poll. The time remaining in the first superframe where K2 missed the poll is given by the second term in parenthesis. This term models the case when the time period after the K2 poll is as long as possible. This means all k 1 calls preceding the kth call in the polling list receive empty polls and return NULL frames. The polling and corresponding NULL return of the K1 end of the kth call is captured in the “+1” term following 2k 1. The last T poll Tsifs captures the empty poll of the K2 end. After this missed poll, the second superframe is captured in the TSF term; it is in this superframe that the K2 end of the call sends its packet. In the third superframe, this packet is delivered to the K1 end of the kth call. To make the delay maximum here, we assume that all k 1 calls preceding it are sending full-sized packets. The 1 2 term represents the time to send the full-sized voice packet to the K1 end in the third super-frame. We note that the time to send it from the K2 end to the AP in the second superframe is subsumed in the last TSF in line 1 of (16). 3.2.5 Management plane Management plane actions consist of initializing variables needed for the operation of the AP and the mobile stations as needed. The minimum length of the CFP is specified in [5] as: 58 Tcfp _ min TB TCF _ end 3Tsifs Tv 2 , (18) where Tv 2 is the time to send one voice packet in CBR mode (or maximum-sized packet in VBR mode) and receive a response. Adding this to shown in (3), yields TSF _ min Tcpf _ min Tcp _ min . The superframe duration should be chosen so that TSF TSF _ min . The CFP repetition interval as shown in figure 3.3 is advertised to be TSF Tcp _ strech , so that the AP can try to gain the medium for the CFP at the end of the CFP repetition interval. In other words, TSF includes the stretching time. The interval between consecutive beacons transmitted by the AP, is set to equal the CFP repetition interval. This limits the number of beacons generated within a CFP to 1 (i.e., at the start), reducing the Beacon overhead. 59 4.0 Analysis In this section, we determine numerical values for the various parameters set through the management plane (Section 4.1), and the maximum call count used in the CAC algorithm at the AP (Section 4.2). Sections 4.3 and 4.4 describe a delay analysis and a loss analysis, respectively. 4.1 Numerical values for system variables Table 4.1 shows the values of certain parameters initialized in the system (see Section 3.2.5) These are determined for both the 2 Mbps and 11 Mbps data rates, from (3), (4) and (18). Table 4.1: Parameter set 2 Data rate (R) Mbps Tcp _ min (ms) Tcp _ stretch (ms) TSF _ min (ms) 2 11 11.9 4.4 10.7 3.2 14.9 5.8 4.2 Numerical values for maximum number of calls Figure 4.1 shows the maximum number of voice calls that can be accommodated in the CBR mode for 2 Mbps and 11 Mbps at two values of the fragmentation threshold (plots of (7)). 60 Figure 4.1: Maximum number of voice calls in CBR mode For example, with a superframe size of 90 ms, 14 and 26 calls can be admitted on the 2 Mbps and 11 Mbps LANs, respectively. We note that fragmentation threshold does not have a significant effect on the maximum number of voice calls that can be admitted at the relatively large values of fragment sizes used in figure 4.1. Table 4.2 compares the maximum number of calls admissible in the CBR mode ( N p ) and VBR mode ( N s ) using both Brady’s and May and Zebo’s voice models for superframes of 75 and 90 ms. With these superframe sizes, our assumption that a packet should be dropped if not served in a superframe holds. For smaller superframe sizes, we cannot make this assumption. Given the difficulty the analyzing loss at these superframe 61 sizes, we undertook a simulation as described in Section 5.0. The loss rate, , in (9), is assumed to be 10 -3 . Table 4.2: Maximum number of voice calls: B (Brady’s model) and MZ (May and Zebo model) TSF (ms) 75 90 Np FH(2 Mbps) N S (B) N S (MZ) Np 12 14 22 26 27 32 22 27 DS (11 Mbps) N S (B) N S (MZ) 41 52 51 65 4.3 Delay results The maximum delay values determined using (12) are plotted in figure 4.2 for the CBR mode. Delays for both directions k1 k 2 and k 2 k1 at both LAN rates, 2 Mbps and 11 Mbps, are shown. For example, if a superframe size of 90ms is used, then total delays of 211 and 303 msec will be experienced in the k1 k 2 and k 2 k1 directions, respectively, for the 802.11 portion of the voice call (on a 11Mbps LAN). Figure 4.2: Total Delay in CBR mode 62 Figures 4.3 and 4.4 show the total delay experienced by packets in the VBR mode for the k 2 k1 direction. Figure 4.3: Total delay for the VBR mode of operation (2 Mbps LAN) packets (plots of total delay using (12) with the minimum and maximum delays of (15) and (16)). We only plot the k 2 k1 direction delays because these are larger than the delays in the opposite direction. Since these delays are dependent on the polling position of the call, we plot the delays for various TSF with varying polling position. Equations (15) and (16) do not bound the maximum size of the polling list. For this analysis, this bound is the maximum number of calls that can be admitted in the CBR mode as plotted in figure 4.1. This is because in deriving (16), for the maximum delay in the k 2 k1 63 direction, we assumed that the last superframe has all calls before the kth call sending maximum-sized packets. Since the maximum size of packets is the same in the VBR mode as in CBR, the number of calls in the polling list should be bounded by the maximum number of calls that can be admitted in the CBR mode. These graphs (and the VBR mode delay analysis of Section 3.2.4) demonstrate what happens when the same number of calls are admitted as in the CBR mode, but the operation of the polling scheme is such that when a polled call has nothing to send, its time allocation is immediately freed for use by the next call. Since the maximum number of calls is the same as in CBR, loss will be 0 under this mode of operation. The “saved” time ranges will effectively be used for the random-access (contention) period. The purpose of the VBR mode delay analysis and the graphs of figures 4.3 and 4.4 is then to demonstrate how total delay can increase significantly by using the VBR mode relative to the CBR mode. For example, the total delay incurred by the k 2 k1 direction packets when TSF = 90ms is 265ms in the CBR mode (for the Mbps LAN), while in the VBR mode, it is 347ms for the worst case call (last call on the polling list), hich is call number 14 (same in the CBR and VBR modes). In fact the total delay in the VBR mode is so high, that at TSF 120ms , no voice calls can be admitted (see that the 120ms line does not even appear in figure 4.3). However, in the CBR mode, 19 calls can be admitted, (for the 2Mpbs LAN) with a delay of close to 400ms. 64 Figure 4.4: Total delay for the VBR mode of operation (11 Mbps LAN) 4.4 Error Analysis The 802.11 MAC protocol supports retransmission to handle transmission errors in both PCF and DCF modes. However, retransmissions are typically avoided for real-time traffic due to delay constraints. Here, we examine whether or not some form of error correction is required for voice traffic. Our analysis takes into account two burst error models. Both are two-state continuous time Markov chains as shown in figure 4.5 [24]. The parameters for the two models are given in table 4.3. The first burst error model used to characterize fading is from [24]. The second model is more realistic with higher BERs. The holding times are rough estimates. Indications are that these will be larger, which only improves the probability of the channel holding its state during a packet transmit time. 65 Bit Error Rate BERG Good (G) BERG Bad (B) Figure 4.5: Model of a wireless channel Table 4.3: Parameters for burst error models Mode BER l G 1 10-10 10-4 2 BER B -5 10 10/sec 30/sec 10-2 20/sec 10/sec The time to transmit a voice packet of payload size bits is given by: T pkt hP R (19) Three cases are possible: Case 1: When a voice packet transmission starts, the channel is in the good state, and there is no transition out of this state before packet transmission completes. Case 2: When a voice packet transmission starts, the channel is in the bad state, and there is no transition out of this state before packet transmission completes. Case 3: All other possibilities; packet transmission starts with the channel in either state and the channel undergoes one or more transitions before packet transmission completes. Using the memoryless property of the exponential distribution and by neglecting propagation delays, the probabilities of the three cases can be derived to be: 66 p case1 pG P(G Tv pkt ) pcase2 p B P( B Tv pkt ) e e Tv pkt Tv p kt pcase3 1 pcase1 pcase2 , (20) (21) (22) where pG and pB are the probabilities of starting a packet transmission when the channel is in the good or the bad state, respectively, and are given by: pG pB (23) The probabilities of a packet error in the three cases are approximated by: case1 1 (1 BERG ) ( v h P ) (24) case2 1 (1 BER B ) ( v h P ) (25) case3 case2 (26) Combining the probabilities of the three cases, given by (20) to (22), with the probability of packet errors in the three cases, given by (24) to (26), yields the total packet error probability as pe ( pcase1 case2 pcase2 case2 pcase3 2 ) (27) where a worst-case error rate is assumed if case 3 happens, i.e., that all bits are subject to BER B. In both CBR and VBR modes, the largest-sized voice packets are: v c(TSF Pmin ) bits. (28) This upper bound of pe is plotted against TSF in figure 4.6 for error models 1 and 2. The 11Mbps network experiences a higher packet error rate even though the packet 67 transmission time can be expected to be shorter owing to the higher data rate. This is because DS packets have a larger preamble than FH packets and preambles are transmitted at 1Mbps for compatibility reasons. Figure 4.6: Packet error rates For 90 ms TSF, a packet error rate of approximately 10-2 and 0.44 for model 1 and model 2, respectively, are observed from the graphs. For voice, with a loss tolerance of 10-3, these error rates are high. This shows a need for error correction. Errors can be handled in one or more of the three ways described in Section 3.2.3.6. Given that holding times in the “bad” error state are high, immediate retransmissions may fail with high probability. 68 5.0 Simulation This section describes a simulation of an 802.11 wireless LAN with both the polling and random-access periods. The purpose of this simulation is to understand the VBR mode of operation with some allowed loss ( = 10-3). Thus, we relax the assumption of zero loss made in Section 4.3 for the VBR mode delay analysis. The mode of operation simulated is mostly the same as described in Section 3.2.3. Stations send variable sized packets. Voice call ends are polled only once per superframe. The CFP is terminated when the AP finishes polling all the stations on its polling list, or if it is not able to poll all stations before the scheduled end of the CFP, it ends the CFP and in the next superframe starts where it left off. The simulation uses fixed superframe sizes. Stations (AP included) know the amount of time remaining in the CFP. This is possible because at the start of the CFP, the AP transmits a Beacon frame indicating the maximum duration of the CFP. Stations keep track of the amount of time lapsed since the beginning of the CFP. Before polling a station, the AP does the following: 1. Checks to see if it has data stored for the call end it is about to poll. If it does have data stored for the call end and there is enough time to transmit the data and receive at least a 32-byte packet from the call end, the AP transmits a Poll + Data frame. If the time is sufficient for only data transmission, then the AP transmits the Data frame (i.e., with no Poll) and ends the CFP. It begins by polling that call end in the next superframe. If no time remains, it transmits the CF-End and in the next superframe starts by transmitting the Poll + Data or Poll frame to that call end. 69 2. If there is no data stored at the AP for the call end being polled, the AP simply transmits the Poll frame if there is sufficient time to receive at least a 32 byte packet from the station. If the time is insufficient, it ends the CFP and starts by polling that call end in the next superframe. On being polled, the voice call ends do the following: 1. If the call end receives a Poll + Data frame, it transmits the Data + Ack frame, if it has data to send and there is sufficient time for the transmission. If there is insufficient time (end of the CFP), the call end transmits the More Data frame, indicating to the AP that it has data to transmit. The AP begins the next superframe by polling the call end. 2. If the call end has no data stored, it transmits the Null frame. We made an assumption that stations do not fragment voice packets. For example, if 90 ms (96 bytes) of voice data is waiting for transmission, but there is only enough time to transmit a 32-byte packet, the stations do not fragment the 96-byte packet into 32byte packets for transmission. Instead, they hold on to the packet (and potentially build a bigger packet) until there is sufficient time to transmit the whole packet. This can be relaxed in future simulations since delay is a consideration. Results for four values of TSF are shown figure 5.1 for the 2Mbps LAN. At a TSF of 120ms, the delays in the k2 k1 direction are more than 400ms making the usage of this superframe size infeasible. Since delays vary with the number of calls admitted, the x-axis is the number of calls admitted. Table 5.1 shows a comparison of the number of calls and corresponding delays in the two directions for the CBR and VBR modes. More calls can be admitted in the VBR mode, but delays experienced are larger. For the 2Mbps 70 Delay for Tsf = 60 m s Delay curve for Tsf of 30 m s K1-K2 2 Mbps K2-K1 2 Mbps K1-K2 2 Mbps K2-K1 2 Mbps 600 - 700 MZ MZ B B 600 Delay in ms Delay in ms 800 400 200 500 K1-K2 2 Mbps K2-K1 2 Mbps K1-K2 2 Mbps K2-K1 2 Mbps - B B MZ MZ 8 12 14 Num ber of calls 400 300 200 100 0 0 0 2 4 Num ber of calls 6 6 8 10 Delay for Tsf of 90 m s 800 500 K1-K2 2 Mbps K2-K1 2 Mbps K1-K2 2 Mbps K2-K1 2 Mbps 1000 Delay in ms Delay in ms 600 18 20 Delay for Tsf = 120 m s 1200 K1-K2 2 Mbps - MZ K2-K1 2 Mbps - MZ K1-K2 2 Mbps - B K2-K1 2 Mbps - B 700 16 400 300 200 800 - B B MZ MZ 600 400 200 100 0 0 14 15 16 17 18 19 20 21 Num ber of calls 22 23 24 25 26 22 24 26 28 30 Num ber of calls 32 Figure 5.1: Simulation results with loss of 10-3 for different super frames sizes: B: Brady model; MZ: May-Zebo model LAN, the best performance is achieved by running the LAN in VBR mode with a superframe size of 90ms; 22 calls can be accommodated with delays below 400ms, while in the CBR mode, 19 calls can be accommodated with a superframe size of 120ms. For the 11Mbps LAN, in the VBR mode, a maximum of 40 calls can be accommodated within the 400ms delay constraint and 10-3 loss constraint at a super-frame size of 90ms, while in the CBR mode a maximum of 34 calls can be accommodated with a super-frame size of 120ms. 71 34 36 Table 5.1: Comparison of CBR and VBR modes CBR (analysis) 11 Mbps Delay Delay k1 k2; N k1 k2; k2 k1 k2 k1 91;130 6 91;123 151;220 16 151;213 182;265 25 211;303 272;400 34 271;393 2 Mbps TSF (ms) 30 60 90 120 N 1 8 14 19 VBR (simulation; Brady’s model) 2 Mbps 11 Mbps Delay Delay N k1 k2; N k1 k2; k2 k1 k2 k1 4 260;311 21 268;386 14 255;330 26 258;321 22 234;326 40 286;388 0 0 - 72 6.0 Conclusion The PCF mode of the 802.11 MAC protocol was designed for real-time services. This work was carried out to determine whether the PCF mode was indeed suitable to carry telephony traffic. To accomplish this a number of design choices had to be made: determining the architecture of the network and the interfaces supported by the various entities (wireless or wired), the protocol stack for carrying voice at the different endpoints, and the timing method to be used at receivers for packet reconstruction, to name a few. The problem was approached in two ways: an analysis and a simulation. We demonstrated that the PCF mode of the 802.11 MAC protocol can indeed be used to carry telephony traffic. Using a CAC algorithm to control the number of calls admitted to the polling list can provide delay guarantees. The simplest mode in which to run the LAN is a Constant Bit Rate (CBR) mode. In this mode, build-out delays at receivers can be computed. In this mode, since all calls experience the same delay, interpoll periods should be chosen for the most stringent delay requirement; however, this could limit the number of voice calls that can be admitted. A more complex Variable Bit Rate (VBR) mode of operation can be used to take advantage of statistical multiplexing and provide differential delays for intra-LAN calls vs. calls to wired endpoints. Finally, our loss analysis showed that voice packets suffer high packet errors indicating the need for error correction. 73 Appendix A /************************************************************************************/ IEEE 802.11 Wireless LAN Simulation (VBR mode of operation) Nabeel Cocker ncocker@purros.poly.edu /************************************************************************************/ #include <iostream> #include <math.h> #include <stdlib.h> #include <time.h> #include <stdio.h> int poll (int start, int Ns, int Tsf, int tsfval); void poll_once(double time_left, int end, int call); double timeleft_in_Tsf(int tsf, double stime, int val); double tmaxmpdu(int frag_size); double tcpmin(void); double Tx_to_AP(double waited_for); double exponential(double mean); void set_delay(int call, int end, int tsf, int tsfval); void printstats(int Nstut, int N, FILE *ptr); void initialize_polling_list(int Nstut); void sums(int Nstut); void initalize_avgs(int Nstut); void set_totals(int tsf, int c); double coding_rate = ((double)32/30); /* coding rate in bytes/milliseconds */ #define RTP_H 12 #define LLC_H 3 #define P_FH 24 #define H_R_L (RTP_H + LLC_H) #define MAC_H_FH (34 + 8 + P_FH) #define h_FH (RTP_H + LLC_H + MAC_H_FH) #define mfixed 2304 #define Rc 1000 #define R_FH 11000 #define B 40 #define CF_End 20 #define TcfendF ((CF_End + P_FH)*8.0/(double)Rc) #define Tbeacon ((B + P_FH)*8.0/(double)Rc) #define T_B_CF_End (((B + CF_End) + 2*P_FH)*8.0/(double)Rc) #define Tsifs 0.028 #define Tslot 0.050 74 #define Ack 14 #define Tack (8.0*(Ack + P_FH)/(double)Rc) #define RTS 20 #define CTS 14 #define Trts (8.0*(RTS + P_FH)/(double)Rc) #define Tcts (8.0*(CTS + P_FH)/(double)Rc) #define TpnFH (2*8.0*MAC_H_FH/(double)Rc + 2.0*Tsifs) #define TpF (MAC_H_FH*8.0/(double)Rc) #define Tpoll TpF #define Tnull Tpoll #define TpnDS (2*8.0*MAC_H_DS/(double)Rc + 2.0*(double)Tsifs) #define Tminpkt 30 #define P_B 0.43 #define P_MZ 0.35 #define MAX_DELAY 400.0 #define MAX_DIF_VALS 15 // size of the TSF array #define MAX_TSFS 10000 #define MAX_CALLS 100 #define END 2 #define MEAN_ON 1000 #define MEAN_OFF 1350 /* call 0 = call A, call 1 = call B, .. */ struct { double lastpolled[END]; double delaysofar[END]; double maxdelay[END]; double mindelay[END]; double pkt_left[END]; double head_of_pkt[END]; double state_end_time[END]; double pkt_created[END]; double pkt_left_created[END]; double tx_to_AP[END];//size in tx time of pkt at the AP: end1 is stored in index 2 and viceversa double pkt_at_AP[END]; double total_numberofpkts[END];//total number of packets double totalloss[END]; //total loss double talkspurt_length[END]; double silence_length[END]; int number_of_tspurts[END]; bool isintalkspurt[END]; } calls[MAX_CALLS]; //#define NSTUT 15 double simtime = 0.0, TSF[MAX_DIF_VALS] = {120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0,120.0}, overallloss[MAX_DIF_VALS][END] = {{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0. 0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0}}, totalpkts[MAX_DIF_VALS][END] = {{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0. 0},{0.0,0.0},{0.0,0.0},{0.0,0.0},{0.0,0.0}}, 75 min_overall_delay[END] = {0.0,0.0}, max_overall_delay[END] = {0.0,0.0}; double maxdelay[MAX_CALLS][END], mindelay[MAX_CALLS][END], totpkt[MAX_CALLS][END], totloss[MAX_CALLS][END]; double tx_32_bytes; FILE *fopen(); FILE *fptr, *fptr2; /************************************************************************************/ /************************************************************************************/ /************************************************************************************/ bool poll_me_again; int poll_end = 0; main () { int tsfsize, /*for the different tsf's*/ startpoll=0, NSTUT[MAX_DIF_VALS] = {30,31,32,33,34,35,36,37,38,39,40,41,42,43,44}, different_Tsf_vals, n, rand_seed, call_end, Tsf; /*superframes*/ fptr = fopen("New_120_11_b.txt", "w"); fptr2 = fopen("New_120_11_b_6.csv", "w"); rand_seed = time(NULL); srand(rand_seed); //**//**fprintf(fptr,"Random number seed = %d\n",rand_seed); for (different_Tsf_vals = 0; different_Tsf_vals < MAX_DIF_VALS; different_Tsf_vals++) { initalize_avgs(NSTUT[different_Tsf_vals]); // Run the simulation n times to gain confidence in the results. // Random number generator gets reinitialized to a different seed because of different time for (n=0; n<10; n++) { startpoll = 0; simtime = Tbeacon + Tsifs; initialize_polling_list(NSTUT[different_Tsf_vals]); for (Tsf = 0; Tsf < MAX_TSFS; Tsf++) { startpoll = poll(startpoll, NSTUT[different_Tsf_vals],Tsf, different_Tsf_vals); simtime = TSF[different_Tsf_vals]*(Tsf+1) + Tbeacon + Tsifs; } 76 /* Sum up delays, losses & other stats for each call for this TSF */ sums(NSTUT[different_Tsf_vals]); } set_totals(different_Tsf_vals, NSTUT[different_Tsf_vals]); //**fprintf(fptr,"\n\n%.1f\n", TSF[different_Tsf_vals]); // Print stats for individual calls: for(call_end=0; call_end<END; call_end++) { max_overall_delay[call_end] = 0.0; min_overall_delay[call_end] = 0.0; } printstats(NSTUT[different_Tsf_vals],n, fptr); // Print stats for aggregate of all calls: for(call_end=0; call_end<END; call_end++) { //(call_end == 0)? fprintf(fptr,"\nTotal End 1s Stats\n"):fprintf(fptr,"\nTotal End 2s Stats\n"); //(call_end == 0)? fprintf(fptr2,"%d,", NSTUT[different_Tsf_vals]):fprintf(fptr2," ,"); //fprintf(fptr,"Total pkts = %.1f, total loss = %.1f, perc. loss = %.2f\n", totalpkts[different_Tsf_vals][call_end],overallloss[different_Tsf_vals][call_end],100*(overallloss[different _Tsf_vals][call_end]/totalpkts[different_Tsf_vals][call_end])); //fprintf(fptr2,"%.3f, %.3f,",min_overall_delay[call_end], max_overall_delay[call_end]); //fprintf(fptr2,"%.1f, %.1f, %.2f\n", totalpkts[different_Tsf_vals][call_end],overallloss[different_Tsf_vals][call_end],100*(overallloss[different _Tsf_vals][call_end]/totalpkts[different_Tsf_vals][call_end])); } } fclose(fptr); fclose(fptr2); } /************************************************************************************/ /************************************************************************************/ /************************************************************************************/ /************************************************************************************/ double tmaxmpdu(int frag_size) /* time to transmit a PDU of certain size */ { return 8.0*(((double)(frag_size + H_R_L)/(double)R_FH) + ((double)MAC_H_FH/(double)Rc)); } /************************************************************************************/ double tcpmin() /* defines minimum contention period duration */ 77 { return 2*Tsifs + 2*Tslot + 8*Tack + tmaxmpdu(mfixed); } /************************************************************************************/ double Tx_to_AP(double pkt_size) /* time from start of transmission at source to arrival of the last bit at the base station */ { return 8.0*((coding_rate*pkt_size + H_R_L)/(double)R_FH + MAC_H_FH/(double)Rc); } /************************************************************************************/ double timeleft_in_Tsf(int tsf, double stime, int val) { return ((TSF[val]*(tsf + 1) - (tcpmin() + Trts + Tcts + + 2*Tsifs + Tack + tmaxmpdu(mfixed)+ TcfendF + Tsifs)) - stime); /* ^^ contention period ^^^ stretching ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ end of CFP^ */ } /************************************************************************************/ double exponential(double mean) //returns the amount of time the call end will be in the current state (on/off) expo. dist. { return (-1*mean*log(rand()/(double) RAND_MAX)); } /************************************************************************************/ void initialize_polling_list(int Nstut) { float prob; int c, end; double expo; //printf("Initializing\n"); for(c=0; c < Nstut; c++) { for(end=0; end<2; end++) { calls[c].maxdelay[end] = 0.0; calls[c].mindelay[end] = 0.0; calls[c].pkt_left[end] = 0.0; 78 calls[c].totalloss[end] = 0.0; calls[c].pkt_at_AP[end] = 0.0; calls[c].total_numberofpkts[end] = 0.0; calls[c].tx_to_AP[end] = 0.0; calls[c].pkt_left_created[end] = -1.0; prob = (float)rand()/(float)RAND_MAX; if (prob <= P_B) { calls[c].isintalkspurt[end] = true; calls[c].number_of_tspurts[end] = 1; expo = exponential(MEAN_ON); //**fprintf(fptr, "Expo ON = %f\n",expo); calls[c].state_end_time[end] = simtime + expo; calls[c].head_of_pkt[end] = simtime; } else { calls[c].isintalkspurt[end] = false; expo = exponential(MEAN_OFF); //**fprintf(fptr, "Expo OFF = %f\n",expo); calls[c].state_end_time[end] = simtime + expo; calls[c].head_of_pkt[end] = calls[c].state_end_time[end]; } } } } /***********************************************************************************/ void set_delay(int call, int index, int tsf, int tsfval) { double delay; delay = simtime - calls[call].pkt_created[index]; //**fprintf(fptr, "Setting Delays for call %d end %d. Delay = %.3f ms\n", call,index,delay); if (delay > MAX_DELAY ) { calls[call].totalloss[index] += calls[call].pkt_at_AP[index]; //fprintf(fptr2,"%.1f\n", calls[call].pkt_at_AP[index]); } if(calls[call].maxdelay[index] < delay) { calls[call].maxdelay[index] = delay; } if(calls[call].mindelay[index] == 0.0) { calls[call].mindelay[index] = delay; } 79 else if (calls[call].mindelay[index] > delay) { calls[call].mindelay[index] = delay; } else{} } /***********************************************************************************/ void initalize_avgs(int Nstut) { int c,end; for (c=0; c< Nstut; c++) { for(end=0; end<2; end++) { maxdelay[c][end] = 0.0; mindelay[c][end] = 0.0; totpkt[c][end] = 0.0; totloss[c][end] = 0.0; } } } /************************************************************************************/ void set_totals(int tsf, int c) { int call, end; for(end=0; end<END; end++) { for(call=0; call<c; call++) { overallloss[tsf][end] += totloss[call][end]; totalpkts[tsf][end] += totpkt[call][end]; } } } /*************************************************************************************/ void sums(int Nstut) { int c, end; for (c=0; c < Nstut; c++) { for(end=0; end < 2; end++) { 80 maxdelay[c][end] += calls[c].maxdelay[end]; mindelay[c][end] += calls[c].mindelay[end]; totpkt[c][end] += calls[c].total_numberofpkts[end]/30.0; totloss[c][end] += calls[c].totalloss[end]/30.0; } } } /************************************************************************************/ void printstats(int Nstut, int N, FILE *ptr) { int c, end; double max[2]= {0.0,0.0}, min[2]={0.0,0.0}, totpkts[2]={0.0,0.0}, totlosspkts[2]={0.0,0.0}; for (c=0; c< Nstut; c++) { for (end=0; end < END; end++) { if(min_overall_delay[end]== 0) { min_overall_delay[end]= mindelay[c][end]; } if(mindelay[c][end] < min_overall_delay[end]) { min_overall_delay[end]= mindelay[c][end]; } if(maxdelay[c][end] > max_overall_delay[end]) { max_overall_delay[end]= maxdelay[c][end]; } } } for (c=0; c< Nstut; c++) { for (end=0; end < END; end++) { min[end] += mindelay[c][end]/(double) N; max[end] += maxdelay[c][end]/(double) N; totpkts[end] += totpkt[c][end]; totlosspkts[end] += totloss[c][end]; } } for (end=0; end < END - 1; end++) { fprintf(fptr2,"%d,", c); fprintf(fptr2,"%.3f, %.3f,%.3f, %.3f,", min[end] /(double) Nstut, max[end] /(double) Nstut,min[end+1] /(double) Nstut, max[end +1] /(double) Nstut); fprintf(fptr2,"%.3f, %.3f, %.3f, %.3f, %.3f, %.3f\n", totpkts[end],totlosspkts[end],100*(totlosspkts[end]/totpkts[end]),totpkts[end+1],totlosspkts[end+1],100*(to tlosspkts[end+1]/totpkts[end+1])); } for (c=0; c< Nstut; c++) 81 { //**fprintf(ptr,"Call position on polling list = %d\n", c); //**fprintf(fptr2,"%d\n", c); for (end=0; end < END; end++) { //(end == 0)? fprintf(ptr,"End 1s Stats\n"):fprintf(ptr,"End 2s Stats\n"); //**fprintf(ptr,"Minimum Delay = %.3f, Maximum Delay = %.3f\n",mindelay[c][end]/(double) N,maxdelay[c][end]/(double) N); //**fprintf(ptr,"Total number of Pkts = %.3f, Total Loss = %.3f, Percent Loss = %.3f\n", totpkt[c][end]/ N,totloss[c][end]/ N,100*(totloss[c][end]/totpkt[c][end])); //fprintf(fptr2,"%.3f, %.3f\n",mindelay[c][end]/(double) N,maxdelay[c][end]/(double) N); //fprintf(fptr2,"%.3f, %.3f, %.3f\n", totpkt[c][end]/ N,totloss[c][end]/ N,100*(totloss[c][end]/totpkt[c][end])); } } } /************************************************************************************/ int poll (int start, int Ns, int Tsf, int tsfval) { int call, flag=0, end,index; double timeleft; int temp_end; tx_32_bytes = tmaxmpdu(32); if(!(poll_me_again)) { temp_end = 0; } else { temp_end = poll_end; } //**fprintf(fptr,"The starting call is %d the end is %d.\n", start, poll_end); for (call=start; call < Ns; call++) { for (end=temp_end; end <2; end++) { index = (end == 0)?1:0; timeleft = timeleft_in_Tsf(Tsf, simtime, tsfval); if (calls[call].tx_to_AP[index] > 0.0 && timeleft > 0.0) { if (timeleft >= calls[call].tx_to_AP[index] + Tsifs + tx_32_bytes + Tsifs) /*enough time for tx of data at AP to call end and receiving at least one data pkt*/ { //**fprintf(fptr,"The pkt at the AP was %f long and belongs to call %d end %d.\n",calls[call].tx_to_AP[index],call,index); simtime += calls[call].tx_to_AP[index]; set_delay(call,index,Tsf,tsfval); //sets the delays simtime += Tsifs; //**fprintf(fptr, "Polling call %d end %d!\n",call,end); 82 poll_once(timeleft,end,call); calls[call].tx_to_AP[index] = 0.0; calls[call].pkt_at_AP[index] = 0.0; } else if (timeleft >= calls[call].tx_to_AP[index] + Tsifs ) /* Send only a data frame to the end!*/ { simtime += calls[call].tx_to_AP[index]; set_delay(call,index,Tsf,tsfval); //**fprintf(fptr, "No time for poll, only transmission: Timeleft = %f\n", timeleft); poll_me_again = true; poll_end = end; calls[call].tx_to_AP[index] = 0.0; calls[call].pkt_at_AP[index] = 0.0; break; } else // no time left { poll_me_again = true; poll_end = end; //**fprintf(fptr, "No time for poll, Timeleft = %f\n", timeleft); break; } } else { if (timeleft >= (Tpoll + Tsifs + tx_32_bytes + Tsifs)) { simtime += Tpoll + Tsifs; //**fprintf(fptr,"Polling call %d end %d!\n",call,end); poll_me_again = false; poll_end = (end == 0) ? 1:0; poll_once(timeleft, end,call); } else { //**fprintf(fptr, "No time for poll, Timeleft = %f\n", timeleft); poll_me_again = true; poll_end = end; break; } } //**fprintf(fptr,"The call polled was call %d end %d!\n", call,end); if(temp_end > 0) temp_end = 0; } if (poll_me_again) { //**fprintf(fptr,"Exiting to poll again end %d.\n", poll_end); break; /* break out of the loop, given that the time has expired */ } if (call == (start - 1)) break; 83 if (start !=0 && call == (Ns -1) ) call = -1; } return (poll_me_again) ? call : 0; } /************************************************************************************/ void poll_once(double time_left, int end, int call) { int index, silence, spurt,s; double spurt_size[20], silence_size[20],pkt = 0.0, timediff = 0.0, pkt_size = 0.0, total_pkt, quantized_form, trans, time_in_next_state, time_out_of_state; index = (end == 0)? 1:0; spurt = -1; silence = -1; if(calls[call].isintalkspurt[end]) { //**fprintf(fptr,"Call %d end %d is in a talkspurt\n",call,end); if(simtime <= calls[call].state_end_time[end]) { pkt_size = simtime - calls[call].head_of_pkt[end]; quantized_form = floor(pkt_size/30.0)*30.0; total_pkt = quantized_form + calls[call].pkt_left[end]; //**fprintf(fptr,"Pkt size = %f\n",total_pkt); if(calls[call].pkt_left[end] !=0.0) { calls[call].pkt_created[end] = calls[call].pkt_left_created[end]; } else { calls[call].pkt_created[end] = calls[call].head_of_pkt[end]; } if(time_left >= (trans = Tx_to_AP(total_pkt)) && total_pkt > 0.0) { //**fprintf(fptr,"Pkt transmitted! of call %d, end %d\n",call,end); calls[call].head_of_pkt[end] += quantized_form; calls[call].total_numberofpkts[end] += total_pkt; simtime += trans + Tsifs; calls[call].tx_to_AP[end] = trans; calls[call].pkt_at_AP[end] = total_pkt; calls[call].pkt_left[end] = 0.0; poll_me_again = false; poll_end = (end == 0)?1:0; } else if (total_pkt > 0.0 && trans < time_left) { poll_me_again = true; 84 poll_end = end; } else { //**fprintf(fptr,"Was in TS and no pkt to transmit!\n"); simtime += Tnull; poll_me_again = false; poll_end = (end == 0)?1:0; } } else//was in TS and simtime > calls[call].state_end_time[end] { if(calls[call].pkt_left[end] != 0.0) { calls[call].pkt_created[end] = calls[call].pkt_left_created[end]; } else { calls[call].pkt_created[end] = calls[call].head_of_pkt[end]; } do { time_out_of_state = simtime - calls[call].state_end_time[end]; //**fprintf(fptr, "The DO WHILE loop 1, time_out_of_state = %.3f\n",time_out_of_state); if(calls[call].isintalkspurt[end]) { //(spurt == -1)?//**fprintf(fptr,"Call transitioned!\n"):fprintf(fptr,"Call still transitioning, spurt= %d\n",spurt); spurt++; spurt_size[spurt] = calls[call].state_end_time[end] - calls[call].head_of_pkt[end]; //**fprintf(fptr, "Size of the spurt = %.3f\n", spurt_size[spurt]); calls[call].head_of_pkt[end] = calls[call].state_end_time[end]; } else { //(silence == -1)?fprintf(fptr,"Call transitioned!\n"):fprintf(fptr,"Call still transitioning, silence=\n",silence); silence++; silence_size[silence] = time_in_next_state; calls[call].head_of_pkt[end] = calls[call].state_end_time[end]; } calls[call].isintalkspurt[end] = !(calls[call].isintalkspurt[end]); time_in_next_state = exponential((calls[call].isintalkspurt[end])?MEAN_ON:MEAN_OFF); //**fprintf(fptr, "Time_in_next_state = %f\n",time_in_next_state); calls[call].state_end_time[end] = calls[call].state_end_time[end] + time_in_next_state; }while(time_out_of_state > time_in_next_state); //**fprintf(fptr, "Spurts = %d\n",spurt); if (spurt == 0) { total_pkt = ceil(spurt_size[0]/30.0)*30.0; } else if(spurt > 0) { 85 for(s=0; s<spurt; s++) { if(silence_size[s] >= 30.0) { pkt_size += ceil(spurt_size[s]/30.0)*30.0; } else { pkt_size += ceil((spurt_size[s] + silence_size[s])/30.0)*30.0; } } total_pkt = pkt_size + calls[call].pkt_left[end]; } else { //**fprintf(fptr, "The ELSE ! spurt = %d!!\n", spurt); total_pkt = 0.0; } timediff = simtime - calls[call].state_end_time[end]; if (spurt != -1 && calls[call].isintalkspurt[end] && time_out_of_state > 30.0) { pkt = floor(time_out_of_state/30.0)*30.0; calls[call].head_of_pkt[end] += pkt; total_pkt += pkt; } //**fprintf(fptr,"The size of total pkt is %f.\n",total_pkt); trans = Tx_to_AP(total_pkt); if(total_pkt > 0.0 && time_left >= trans) { //**fprintf(fptr,"Transmitted the pkt!\n"); calls[call].total_numberofpkts[end] += total_pkt; simtime += trans + Tsifs; calls[call].tx_to_AP[end] = trans; calls[call].pkt_at_AP[end] = total_pkt; calls[call].pkt_left[end] = 0.0; poll_me_again = false; poll_end = (end == 0)?1:0; } else if (total_pkt > 0.0 && trans < time_left) { calls[call].pkt_left[end] = total_pkt; poll_me_again = true; poll_end = end; } else { //**fprintf(fptr,"Was in TS and transitioned with no pkt to transmit!\n"); simtime += Tnull; poll_me_again = false; poll_end = (end == 0)?1:0; } } } 86 /***********************************************************************************/ else // end was not in a talkspurt { //**fprintf(fptr, "Call %d, end %d was not in a TS\n",call,end); if(simtime <= calls[call].state_end_time[end]) { //**fprintf(fptr, "Still not in TS\n"); //if there are any pkts transmit them if(calls[call].pkt_left[end] != 0.0) { //**fprintf(fptr, "There is still a pkt to transmit!\n"); calls[call].pkt_created[end] = calls[call].pkt_left_created[end]; if(time_left >= (trans = Tx_to_AP(calls[call].pkt_left[end]))) { calls[call].total_numberofpkts[end] += calls[call].pkt_left[end]; simtime += trans + Tsifs; calls[call].tx_to_AP[end] = trans; calls[call].pkt_at_AP[end] = calls[call].pkt_left[end]; calls[call].pkt_left[end] = 0.0; } else if (time_left < trans) { //**fprintf(fptr,"Poll me again! I was not in a TS though!!!!\n"); poll_me_again = true; poll_end = end; } else { simtime += Tnull; } } } else { //simtime > state_end_time //**fprintf(fptr, "Transitioned from not in TS!\n"); calls[call].pkt_created[end] = calls[call].state_end_time[end]; if (calls[call].pkt_left[end] > 0.0) calls[call].pkt_created[end] = calls[call].pkt_left_created[end]; do { //**fprintf(fptr, "The DO WHILE loop 2\n"); time_out_of_state = simtime - calls[call].state_end_time[end]; if(calls[call].isintalkspurt[end]) { spurt++; spurt_size[spurt] = calls[call].state_end_time[end] - calls[call].head_of_pkt[end]; calls[call].head_of_pkt[end] = calls[call].state_end_time[end]; } else { silence++; if(silence > 0) silence_size[silence -1] = time_in_next_state; 87 calls[call].head_of_pkt[end] = calls[call].state_end_time[end]; } calls[call].isintalkspurt[end] = !calls[call].isintalkspurt[end]; time_in_next_state = exponential((calls[call].isintalkspurt[end])?MEAN_ON:MEAN_OFF); //**fprintf(fptr, "Time_in_next_state = %f , time_out_of_state = %f\n",time_in_next_state,time_out_of_state); calls[call].state_end_time[end] = calls[call].state_end_time[end] + time_in_next_state; } while(time_out_of_state > time_in_next_state); if (spurt == 0) { total_pkt = ceil(spurt_size[0]/30.0)*30.0; } else if(spurt > 0) { for(s=0; s<spurt; s++) { if(silence_size[s] >= 30.0) { pkt_size += ceil(spurt_size[s]/30.0)*30.0; } else { pkt_size += ceil((spurt_size[s] + silence_size[s])/30.0)*30.0; } } total_pkt = pkt_size + calls[call].pkt_left[end]; } else if (time_out_of_state > 30.0 && spurt == -1) { pkt_size = floor(time_out_of_state/30.0)*30.0; calls[call].head_of_pkt[end] += pkt_size; total_pkt = pkt_size + calls[call].pkt_left[end]; } else { //**fprintf(fptr, "No spurt! = %d\n", spurt); total_pkt = 0.0; } timediff = simtime - calls[call].state_end_time[end]; if (spurt != -1 && calls[call].isintalkspurt[end] && timediff > 30.0) { pkt = floor(timediff/30.0)*30.0; calls[call].head_of_pkt[end] += pkt; total_pkt += pkt; } //**fprintf(fptr,"Total pkt size = %f.\n",total_pkt); if(total_pkt > 0.0 && time_left >= (trans = Tx_to_AP(total_pkt))) { //**fprintf(fptr,"Transmited the pkt!\n"); calls[call].total_numberofpkts[end] += total_pkt; simtime += trans + Tsifs; calls[call].tx_to_AP[end] = trans; calls[call].pkt_at_AP[end] = total_pkt; 88 calls[call].pkt_left[end] = 0.0; poll_me_again = false; poll_end = (end == 0)?1:0; } else if (total_pkt > 0.0 && trans < time_left) { //**fprintf(fptr,"Poll me again. I was not in a TS but transitioned!!!!\n"); calls[call].pkt_left[end] = total_pkt; calls[call].pkt_left_created[end] = calls[call].pkt_created[end]; poll_me_again = true; poll_end = end; } else { //**fprintf(fptr,"Was not in TS, then transitioned and no pkt to transmit!\n"); simtime += Tnull; poll_me_again = false; poll_end = (end == 0)?1:0; } } } //**fprintf(fptr,"End of the poll once function! Call was %d , end was %d \n", call, end); } 89 References [1] ISO/IEC and IEEE Draft International Standards, “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” ISO/IEC 880211, IEEE P802.11/ D10, Jan. 1999. [2] P. Brady, “A Model for Generating On-Off Speech Patterns in Two-Way Conversation,” Bell Syst. Tech. Journal, vol. 48, no. 7, pp. 2245-2272, Sept. 1969. [3] C. E. May and T. J. Zebo, “A summary of speech statistics measured during the TASI-E Rego Park-Ojus field trial,” submitted for publication. [4] ITU-T, “General Characteristics of International Telephone Connections and International Telephone Circuits One-Way Transmission Time” G.114, Feb. 1996. [5] S. Tanenbaum, Computer Networks, 3rd ed., Prentice-Hall, 1996. [6] D. Goodman, R. Valenzuela, K. Gayliard, B. Ramamurthi, “Packet Reservation Multiple Access for local wireless communications”, Proc. 39th IEEE Vehicular Technology Conference, pp. 701-6, 1988. [7] Leon-Garcia and I. Widjaja, Communication Networks, McGraw Hill, 1999. [8] M. J. Karol, Z. Liu, P. Pancha, “The design and performance of wireless MAC protocols,” in Broadband Wireless Communications, pp. 225-236, Springer-Verlag, 1998 (papers from the 9th Tyrrhenian Intl. Workshop on Digital Comm., Sept. 1997). [9] O. Kubbar and H. Mouftah: “Multiple access control protocols for wireless ATM: problems definition and design objectives”, IEEE Comm. Mag., vol. 25, no. 11, pp. 93-9, Nov. 1997. [10] Akyildiz, J. McNair, L. Martorell, R. Puigjaner, Y. Yesha, “Medium access control protocols for multimedia traffic in wireless net-works,” IEEE Net. Mag., vol. 13, no. 4, pp. 39-47, Jul./Aug. 1999. [11] J. Sanchez, R. Martinez, M. Marcellin, “A survey of MAC protocols proposed for wireless ATM,” IEEE Net. Mag., vol. 11, no. 6, pp. 52-62, Nov./Dec. 1997. [12] S. Alwakeel and M. Al-Fawaz, “DPAP: a dynamic polling based access protocol for wireless networks”, Proc. Ninth IEEE PIMRC, pp. 1126-30, 1998. [13] M. Moroney and C. Burkley, “Multiple access protocols for indoor wireless communications”, Proc. IEEE Intl. Conf. on Selected Topics in Wireless Communications, pp. 406-8, 1992. 90 [14] M. Visser and M. El Zarki, “Voice and data transmission over an 802.11 wireless network”, Proc. Sixth IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp. 648-52, Sep. 1995. [15] Crow, I. Widjaja, J. Kim, P. Sakai, “Investigation of the IEEE 802.11 medium access control (MAC) sublayer functions”, Proc. Infocom, pp. 126-33, Apr. 1997. [16] P Crow, I. Widjaja, J. G. Kim, P. T. Sakai: “IEEE 802.11 Wireless Local Area Networks”, IEEE Comm. Mag., vol. 35, no. 9, pp. 116-26, Sep. 1997. [17] J. Stine and G. de Veciana: “Tactical communications using the IEEE 802.11 MAC protocol”, Proc. IEEE Military Communications Conference (Milcom), pp. 575-82, Oct. 1998. [18] J. L. Sobrinho and A.S. Krishnakumar, “Real-Time Traffic over the IEEE 802.11 Medium Access Control Layer,” Bell Labs Technical Journal, Autumn 1996. [19] T. Chen, J. Walrand, D. Messerschmitt, “Dynamic Priority Protocols for Packet Voice,” IEEE JSAC, vol. 7, no. 1, June. 1989, pp. 632-643. [20] W. Montgomery, “Techniques for packet voice synchronization,” IEEE JSAC, vol. 1, no. 6, pp. 1022-8, Dec. 1983. [21] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 1889, January 1996. [22] K. Sriram, T. Lyons, Y-T. Wang, “Anomalies due to delay and loss in AAL2 packet voice systems: Performance and Methods of Mitigation,” IEEE JSAC, vol. 17, no. 1, Jan. 1999, pp. 4-17. [23] Gilbert, “Capacity of a Burst Noise Channel,” Bell Syst. Tech. J., vol. 39, Sept. 1960, pp. 1253-66. [24] M. Veeraraghaven, “Internetworking: Voice over packet-switched networks and IP over X”, 1999. 91