CARRYING VOICE ON IEEE 802.

11 WIRELESS LOCAL
AREA NETWORKS

Table of Contents

List of Figures…………...……………………………………………...…..v
List of Tables………………………………………………………………. vi
1.0 Introduction…………………………………………………………1
2.0 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
3.0 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

1
 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
3.2.4.2 Computation of build-out delay………….. 43
3.2.5 Management plane…………………………………..51
4.0 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
5.0 Simulation………………………………………………………….. 62
6.0 Conclusion…………………………………………………………. 66

Appendix A: Simulation code………………………………………………67

References…………………………………………………………………. 83

2
 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:
Reference source not found
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

3
 List of Tables

2.1 Valid Type/Subtype Combinations………………………………… 11

2.2 To DS/From DS……………………………………………………. 13
3.1 Categorization of Applications…………………………………….. 27
3.2 Parameters…………………………………………………………..39
3.3 Voice Models………………………………………………………. 42
4.1 Parameter Set 2…………………………………………………….. 53
4.2 Maximum Number of Voice Calls…………………………………. 55
4.3 Parameters for Burst of Error Models………………………………58
5.1 Comparison of CBR and VBR modes……………………………... 65

4
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.

5
 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

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.

6
 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

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.

7
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.

8
 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.

9
 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.

10
 BSS 1

STA 1
STA 2

AP
DS
BSS 2
AP
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.

11
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.

12
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).

2.3.1 General frame format

The figure below depicts the general frame format of a MAC frame.

Frame Duration Address Address Address Sequence Address Frame FCS

Control ID 1 2 3 Control 4 Body
13
Octets 2 2 6 6 6 2 6 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 Type Subtype To From More Retry Pwr More WEP Order
Version DS DS Frag Mgt Data

Bits: 2 2 4 1 1 1 1 1 1 1 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.

14
 Table 2.1: Valid Type/Subtype combinations

Type Value Type description Subtype Subtype description

value
00 Management 0000 Association request
00 Management 0001 Association response
00 Management 0110-0111 Reserved
00 Management 1000 Beacon
00 Management 1101-1111 Reserved
01 Control 0000-1001 Reserved
01 Control 1011 Request To Send (RTS)
01 Control 1100 Clear To Send (CTS)
01 Control 1101 Acknowledgement (Ack)
01 Control 1110 Contention Free (CF)-End
10 Data 0000 Data
10 Data 0001 Data + CF-Ack
10 Data 0010 Data + CF-Poll
10 Data 0011 Data + CF-Ack + CF-Ack
10 Data 0100 Null Function (no data)
10 Data 0101 CF-Ack (no data)

iii) 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

15
 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.

16
 Table 2.2: To DS /From DS

To From Address 1 Address 2 Address 3 Address 4 Meaning

DS DS
0 0 Destination Source BSSID N/A Data frame from
Address Address station to station
within a BSS
0 1 Destination BSSID Source N/A Data frame exiting
Address Address the DS
1 0 BSSID Source Destination N/A Data frame destined
Address Address for the DS
1 1 Receiver Transmitte Destination Source WDS frame being
Address r Address Address Address distributed from AP
to AP

i) 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 that

17
 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.

18
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 Duration RA TA FCS

Control

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.

19
2.3.2.1.2 Clear To Send (CTS) frame format

Frame Duration RA FCS

Control

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 Duration RA FCS

Control

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 Duration RA BSSID FCS

Control

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.

20
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 Duration DA SA BSSID Sequence Frame FCS

Control Control Body

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).

21
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:

22
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.

23
 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.

24
 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

25
 DIFS
RTS DATA
SOURCE
SIFS SIFS SIFS
CTS Ack
DESTINATION
DIFS

NAV (RTS)
OTHER NAV (CTS)

NAV (DATA)

Wait for
Defer Access 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 will

26
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 connection-

oriented, 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.

27
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
SIFS SIFS Contention Period

D2+ack
Beacon D1+poll +poll CF-End

U1+ack U2+ack

PIFS SIFS 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.

28
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.

29
 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 CFEnd frame. This is

depicted in figure 14, where the CF-End frame is sent before CFPMaxDuration is

reached.

30
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-real-

time applications, as depicted in table 3.1 below.

Table 3.1: Categorization of applications

Consuming end
Live Stored
endSending

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

31
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 connection-

oriented service. As was explained above, packet-switched connection-oriented services

32
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.

33
 AP Voice
Gateway PSTN

ATM
AP Network

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.

34
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.

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.

35
 Access Point

Poll + Poll + Poll + Poll +

A1 Data B2 Data B1 Data A2 Data

A1 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

Poll + Poll + Poll + Poll +

B2 Data A1 Data B1 Data A2 Data

A1 B1 A2 B2 A1

Figure 3.3: Polling list formation – scheme 2

36
 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.

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.

37
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

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

38
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

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.

39
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

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

40
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.

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.

41
42
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

numbers are computed using the IEEE 802.11 MAC protocol. Table 3.2 lists our notation.

Table 3.2: Parameters

43
 Parameter Symbol Values as assumed for
numerical evaluation
Maximum duration of the superframe (includes TSF Varies
stretching period)
Beacon interval in sec Tb Varies
Voice coding rate in Kbits/sec c 8.5
Transmission rate in Mbits/sec 2 (FH a ) and 11 R 2 (FH) and 11 (DS)
(DS)
Header overheads (all layers except physical h 57 x 8
layer) in bits
Physical layer header size in bits P 16 x 8 and 24 x 8
Maximum number of voice calls in the CBR Np Computed
mode of operation
Maximum number of voice calls in the VBR Ns Computed
mode of operation
Minimum value of the super frame size TSF min Computed
Minimum value of the CP (Contention Period) Tcp min Computed
- random-access
Minimum value of the CFP (Contention-Free Tcfp min Computed
Period) - polling
Maximum size of an MSDU in bits S max SDU 2304 x 8
Fragment threshold size (payload) in bits f 1100 x 8 and 2304 x 8
Beacon size in bits B 40 x 8
CF-end size in bits CFend 4x8
The SIFS interval Tsifs 0.028 ms
A slot time Tslot 0.050 ms
Packetization delay to create one minimum Pmin 30 ms
sized “sample”
Time to send a voice packet generated over a Tv Computed
superframe duration

Time to send an RTS (20 bytes) Trts Computed

Time to send a CTS (14 bytes) Tcts Computed

Time to send an acknowledgment frame Tack Computed

without data (14 bytes)
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

44
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:

(c  ( Pmin  TSF )  h  P )  4
Tv   4Tsifs (1)
R

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

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)

45
  f  h  P 
Tmax  ( m  1)    Tack  2Tsifs   Tlast (5)
 R  

 S max SDU 
where, m    and Tlast is given by:
 f 

S max SDU  f (m  1)  h  P
Tlast   Tack  2Tsifs (6)
R

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

TSF  Tcp  Tovhd

Np  , where (7)
Tv

BP   TSF  Tcp  CFend  P

Tovhd    Tsifs     (8)
 R   Tb  R

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

46
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] 1000 1350 0.43

May and Zebo [3] 352 650 0.35

statistically guaranteeing that loss will be less than some number  . N s is given by

1  2 N s  k 2Ns k
2 Ns
( k Np)2  p (1p)  (9)

2pNs k2Np1 k 
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

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

47
between two packets. For example, assume the first packet took d 1 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.

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

48
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  k1 assuming that the k1 end is placed

on the polling list before the k 2 end.

Tv T
Pmin   Dk 1k 2  Pmin  TSF  v (10)
2 2

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.

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

49
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 2k1  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:

max max

1k 2  Dk 1 k 2  Dk 1 k 2  Dk 1 k 2 and
TDkmax min
 (12)

2  k 1  D k 2  k 1   D k 2  k 1  Dk 2  k 1 
TDkmax max max min
(13)

50
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.

poll Access Point

CFP ends

A1 A2 B1 B2 K1 K2 A1 A2 B1 B2 K1 K2 time
Voice call ends 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

51
goal of this analysis is to analyze the effect on delay and delay variability that arises by

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

1 k 2  Pmin  Tint erpoll    c ( Pmin T SF ) 
(14)

Tint erpoll  TSF  2(k  1)(T poll  Tsifs  Tnull  Tsifs ) 

   c( Pmin  TSF )  (15)
(k  1) T poll  Tsifs    c( Pmin  TSF )  
 2 

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

52
packet transmission time. In CBR, even if only a small packet of payload size cPmin

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

53
delay; the first call’s interpoll delay is TSF , but each subsequent call experiences an

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:

54
   cPmin 
2 k 1  Pmin 
DkVBR 
2
    c Pmin  TSF    3  c Pmin  TSF    
 TSF  Tcp _ strech    k  1   c Pmin  TSF     T  T    
  2
null sifs
 2
  
  cPmin 
2 k  1 T poll  Tsifs  Tnull  Tsifs  
2

(16)

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  c Pmin  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

55
(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:

2 k 1  Pmin  TSF   T poll  Tnull  2Tsifs   2 k  1  1  T poll  Tsifs    TSF 

DkVBR
 1
 2 k  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 2 k  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).

56
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:

Tv
Tcfp _ min  TB  TCF _ end  3Tsifs 
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.

57
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.9 10.7 14.9
11 4.4 3.2 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)).

58
 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

59
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)

FH(2 Mbps) DS (11 Mbps)

TSF (ms)
Np N S (B) N S (MZ) Np N S (B) N S (MZ)
75 12 22 27 22 41 51
90 14 26 32 27 52 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

60
 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

61
in figure 4.1. This is because in deriving (16), for the maximum delay in the k 2  k1

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.

62
 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.

63
 Bit Error Rate

BERG  BERG

Good Bad
(G)
 (B)

Figure 4.5: Model of a wireless channel

Table 4.3: Parameters for burst error models

Mode BER BER  

l G B

1 10-10 10 -5
10/sec 30/sec
2 10-4 10-2 20/sec 10/sec

The time to transmit a voice packet of payload size  bits is given by:

 hP
T  pkt  (19)
R

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:

64
   T
p case1  pG P(G  Tv  pkt )  e v  pkt (20)
 

 T
pcase 2  p B P( B  Tv  pkt )  e v  pkt
(21)
 

p case3  1  p case1  p case 2 , (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)

 case 2  1  (1  BERB ) ( v  h  P ) (25)

 case 3   case 2 (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

p e  ( p case1 case 2  p case 2  case 2  p case3 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

transmission time can be expected to be shorter owing to the higher data rate. This is

65
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.

66
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.

67
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 32-

byte 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

68
 Delay curve for Tsf of 30 m s Delay for Tsf = 60 ms
800 700 K1-K2 2 Mbps -B
K1-K2 2 Mbps - MZ
K2-K1 2 Mbps - MZ 600 K2-K1 2 Mbps -B
600 K1-K2 2 Mbps -B K1-K2 2 Mbps - MZ
500

Delay in ms
K2-K1 2 Mbps - MZ
Delay in ms

K2-K1 2 Mbps -B
400
400
300

200 200
100
0 0
0 2 4 6 8 6 8 10 12 14 16 18 20
Number of calls Number of calls

Delay for Tsf of 90 m s Delay for Tsf = 120 m s

800 K1-K2 2 Mbps - MZ 1200
700 K1-K2 2 Mbps -B
K2-K1 2 Mbps - MZ
K1-K2 2 Mbps - B 1000 K2-K1 2 Mbps -B
600
K2-K1 2 Mbps - B K1-K2 2 Mbps - MZ
Delay in ms

800

Delay in ms
500 K2-K1 2 Mbps - MZ
400 600
300
400
200
100 200

0 0
14 15 16 17 18 19 20 21 22 23 24 25 26 22 24 26 28 30 32 34 36
Number of calls Number of calls

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.

69
 Table 5.1: Comparison of CBR and VBR modes

CBR (analysis) VBR (simulation; Brady’s model)

2 Mbps 11 Mbps 2 Mbps 11 Mbps
Delay Delay Delay Delay
TSF
N k1  k2; N k1  k2; N k1  k2; N k1  k2;
(ms)
k2  k1 k2  k1 k2  k1 k2  k1
30 1 91;130 6 91;123 4 260;311 21 268;386
60 8 151;220 16 151;213 14 255;330 26 258;321
90 14 182;265 25 211;303 22 234;326 40 286;388
120 19 272;400 34 271;393 0 - 0 -

70
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, inter-

poll 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.

71
 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

72
#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}},
min_overall_delay[END] = {0.0,0.0},
max_overall_delay[END] = {0.0,0.0};

73
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;
}

/* Sum up delays, losses & other stats for each call for this TSF */
sums(NSTUT[different_Tsf_vals]);

74
 }

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 */
{
return 2*Tsifs + 2*Tslot + 8*Tack + tmaxmpdu(mfixed);

75
}

/************************************************************************************/

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;
calls[c].totalloss[end] = 0.0;
calls[c].pkt_at_AP[end] = 0.0;

76
 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;
}
else if (calls[call].mindelay[index] > delay)
{

77
 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++)
{
maxdelay[c][end] += calls[c].maxdelay[end];
mindelay[c][end] += calls[c].mindelay[end];

78
 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++)

{
//**fprintf(ptr,"Call position on polling list = %d\n", c);

79
 //**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);
poll_once(timeleft,end,call);
calls[call].tx_to_AP[index] = 0.0;

80
 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;

if (start !=0 && call == (Ns -1) )

call = -1;

81
 }

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;
poll_end = end;
}

82
 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)
{
for(s=0; s<spurt; s++)
{

83
 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;
}
}
}
/***********************************************************************************/
else // end was not in a talkspurt

84
{
//**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;
calls[call].head_of_pkt[end] = calls[call].state_end_time[end];
}

85
 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;
calls[call].pkt_left[end] = 0.0;
poll_me_again = false;

86
 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);
}

87
 References

[1] ISO/IEC and IEEE Draft International Standards, “Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications,” ISO/IEC 8802-
11, 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.

88
[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.

89