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