This file contains text only. You might be able to find more related information (e.g. richer versions that also include figures, mathematical expressions, and errata) at http://uluru.poly.edu/~tmoors/.

---------------------------------

Support of voice services in IEEE 802.11 wireless LANs
Malathi Veeraraghavan, Nabeel Cocker, Tim Moors Polytechnic University
{mv@ poly. edu, ncocke01@ utopia. poly. edu, moors AT ieee.org}

Abstract --The IEEE 802. 11 MAC protocol supports two
modes of operation, a random access mode for non-real-time data
applications, and a polling mode for real-time applications. We
design and analyze a system that uses the polling mode for inter-active
voice traffic. With larger inter-poll periods, more voice
calls can be accommodated, but at the expense of increased delay.
For example, our analysis shows that 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. We also carry out a loss analysis that demon-strates
the need for error correction of voice packets.

I. INTRODUCTION
The IEEE 802.11 wireless LAN [1] is gaining popular-ity
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 ser-vices
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. This is evi-dent
in that most commercially-available offerings only
implement the 802.11 mode of operation that supports
data services, called the Distributed Coordination Func-tion
(DCF) mode, and not the second 802.11 mode of
operation, designed for real-time services, called the
Point Coordination (PCF) mode.

The problem statement of this work is to determine
whether the 802.11 PCF mode is 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 are applicable to any polling-based scheme.

The motivation for this work comes from an observa-tion
that the PCF mode offers a "packet-switched con-nection-
oriented" service, which is well suited for
telephony traffic. Telephony traffic has been shown to
have alternating periods of talk spurts and silences
[2][ 3]. Packet-switched solutions that take advantage of
silences in a given voice call by multiplexing voice data
from other calls are more bandwidth-efficient than cir-cuit-
switched solutions. This has been one of the primary
reasons for the ongoing movement in the telecommuni-

cations industry toward moving telephony traffic from
DS0 based circuit-switched networks on to packet-switched
networks. In wireless networks, where band-width
is more constrained, the use of packet-switched
techniques for carrying voice are indeed needed. While
currently most wireless users use cellular or cordless
telephones within buildings, the availability of an 802.11
wireless LAN will enable a more efficient usage of over-all
wireless bandwidth. By having in-building users use
wireless LAN access for their voice calls, more of the
cellular resources are available for outdoors users and
buildings without 802.11 LANs. Thus, our motivation is
to take advantage of the packet-switched aspect of
802.11 to support bursty telephony traffic, and thus
achieve better overall wireless bandwidth utilization.

The "connection-oriented" aspect of the PCF mode
would allow the network to provide delay guarantees
necessary for interactive voice. The end-to-end delay
requirement for interactive voice is 25ms without echo
cancellers, 150ms with echo cancellers for excellent
quality voice, and 400ms with echo cancellers for
acceptable quality voice [4]. The PCF mode would allow
for delay guarantees to be made for voice calls. In sum-mary,
given the packet-switched and connection-ori-ented
aspects of the PCF mode, the problem addressed
in this paper is to determine how exactly to use the PCF
mode to carry telephony traffic. Problems associated
with the coexistence of DCF and PCF are also addressed.

Section II briefly summarizes the operation of an
802.11 LAN and surveys related work on this topic. Sec-tion
III describes our proposed solution. The solution is
more than simply stating that we use PCF to carry voice.
The IEEE 802.11 specification has many options and
management-settable parameters. Specific choices of
how to operate such aCould not acquire words on page 2 LAN to support voice calls are
required. Section IV describes an analysis to determine
optimal values of inter-poll periods, and characterize the
maximum number of voice calls that can be supported,
end-to-end delays, and packet loss rates. Section V pre-sents
our conclusions.

II. BACKGROUND AND RELATED WORK
This section provides some background information
on 802.11 LANs and reviews prior work on supporting

rection, positive acknowledgments (ACKs) are used.
These are generated in an interesting manner in 802.11.
An ACK for a frame is piggybacked on the next frame
even if the latter is not destined to the same station as the
sender of the previous frame. There is no mechanism to
turn off retransmissions in the PCF mode, or to use dif-ferent
retry counts in the PCF and DCF modes.

Beacons are generated periodically according to the
Beacon interval. Mobile stations awaken at listen inter-vals
(which are multiples of beacon intervals) to hear
beacons. A beacon is sent at the start of a CFP, but if the
CFP duration is larger than the beacon interval then mul-tiple
beacons will be sent during a CFP. The CFPPeriod
(also a management-settable parameter) indicates the
CFP repetition interval. The CFPMaxDuration is also
settable and indicated in beacons. For beacons that arrive
in the middle of a CFP, the CFPRemainingDuration indi-cates
how long is left in the CFP. Thus, if a mobile sta-tion
sleeps and awakens on its listen intervals that may
not coincide with the start of a CFP, it can still determine
the time left in the CFP.

B. Related work
MAC protocols can be classified according to whether
they assign transmission capability to sources in a fixed
manner, at random, or on demand. Fixed assignment
schemes include time-and frequency-division multi-plexing.
Random assignment schemes are typically used
for data traffic. No reservations are made in random
assignment. Random assignment schemes (such as
802.11's DCF) tend to offer large and unbounded delays
when loads are high. For voice calls, this delay may be
acceptable during call setup, but will be less acceptable
at the beginning of each talkspurt, or even within a talk-spurt.
Demand assignment may be either centralized or
distributed. The assignment may be centralized at a con-trolling
node (as in polling for 802.11 PCF), or in a par-ticular
piece of information that circulates amongst
nodes (as in token schemes, although these are not
widely used in wireless networks because tokens can fre-quently
become lost through bit errors or inaccessible
through a station moving out of range). In distributed
demand assigned schemes, nodes request access before
transmitting, shifting the multiple access problem to the
request channel. For example, requests may be sent
using either fixed assignment (e. g. using a bit map ([ 5],
pp. 254-5) or random assignment (e. g. PRMA [6]). Ref-erence
[7] classifies demand assignment schemes as res-ervation
based schemes, such as DQRUMA [8], polling

schemes, or token-ring schemes. Reference [9] makes
the case for either prioritization or polling for demand
assignment rather than reservation schemes because of
packet (burst) access delays associated with the latter.

On the specific topic of how to support voice traffic on
MAC protocols, there is a very rich literature. Since we
cannot list all these papers, we simply list three survey
papers [9]-[ 11]. More specifically, polling based MAC
protocols have been used to support real-time communi-cation
in the wireless environment in several protocols
other than 802.11 (e. g. [12] and [13]). However, given
that 802.11 is now an IEEE standard, papers are focus-sing
on this protocol to support voice. Papers presenting
results from simulating the polling used in the PCF mode
of IEEE 802.11 include [14]-[ 16]. In contrast, our paper
provides an analysis of polling, and suggests not just
how performance varies with the number of calls, but
also how 802.11 parameters should be set to support
voice calls, and provides details about the polling
scheme and method for reconstructing voice timing. Vis-ser
and El Zarki [14] consider voice without echo can-cellers,
and so are forced to use a 20ms superframe
which limits the number of admissible voice calls. Crow
et al. [15], [16] account for transmission errors, but use a
410ms superframe which consumes most of the end-to-end
delay budget for voice in just one hop across the
wireless network. Stine and de Veciana [17] also con-sider
voice using PCF, but emphasize the power con-sumption
aspects of the MAC protocol. Finally, [18]
proposes a scheme for carrying real-time traffic in an ad
hoc 802. 11 LAN (i. e., without an AP), while we only
consider the case with APs since we expect most calls to
be placed from 802.11 phones to wired phones.

III. PROPOSED SOLUTION
This section describes design choices made to carry
interactive voice traffic in the PCF mode. Our solution
consists of (i) stating our architectural assumption, (ii)
defining user plane actions to send voice data, (iii) defin-ing
control plane actions, such as Connection Admission
Control (CAC) to admit only a limited number of users
into the polling list, and (iv) setting Management Infor-mation
Base (MIB) variables.

A. Architectural assumption
Given our motivation to enable voice calls to be made
from 802.11 users to wired, cellular, or Internet tele-phones,
we assume that the network architecture is as
shown in Fig. 3. Access points currently have only two interfaces, an 802.11 interface and an ethernet interface.
ethernet interface supports data traffic sent via the
DCF mode from mobile stations to the APs. On the other
hand, since ethernet does not provide differential Quality
of Service (QoS) support, it is not suitable for real-time
traffic. Instead, the PCF mode of 802.11 could itself be
used from the AP to a voice gateway (see Fig. 3), with
the voice gateway supporting interfaces to the PSTN,
network (for voice over ATM) and to the Internet
(for voice over IP). The voice gateway converts the
802.11 voice protocol stack to PCM voice for use on the
PSTN, voice over an ATM Adaptation Layer (AAL) for
ATM networks, or voice over Real-time Transport Proto-col
UDP/ IP for IP networks. This architecture
allows for end-to-end delay guarantees given that both
PSTN and ATM networks are connection-oriented, next-generation
IP networks are also expected to support a
connection-oriented mode.

In this architecture, by using the PCF mode for voice
traffic between an AP and the voice gateway, a voice call
to a PSTN/ ATM/ IP phone uses the same network
within the 802.11 LAN as an intra-AP call.
Thus, for both intra-AP calls and calls between 802. 11
users and PSTN/ ATM/ IP phones, two ends (both sending
and receiving) are added to the polling list of an AP. In
case of the latter, the voice gateway extracts voice
from received 802.11 frames and carries these
signals on the protocols used on the wide-area networks.

Extensions to allow for multiple APs on the 802. 11
portion of voice calls, and other architectures in which
the voice gateway functionality is located in the APs can
be considered. In these situations, only one voice call
end will be placed on an AP's polling list. These cases
are not included in this paper, and will be studied later.

B. User-plane actions
This section describes how voice packets are carried

Figure 3: Network architecture
End host End host

ce
ATM
network

PSTN

AP
Internet

AP
ethernet
Gateway
on 802.11. We consider two modes of operation: (i) Con-Voi
stant 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, and (ii) Variable Bit Rate (VBR) mode, in
which statistical multiplexing is used and silences in
voice calls are used by other voice calls or data traffic.

First consider whether to send fixed or variable size
voice packets. Given that voice codecs typically produce
a given number of bytes every few msec (for example,
the Truespeech codec produces 32 bytes every 30ms),
one could potentially design the system with fixed size
packets. However, the overhead of protocol layers is sig-The
nificant (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.

The timing method used for packet voice needs to be
determined. The two choices are Complete Timing Infor-ATM
mation (CTI) and Null Timing Information (NTI)
[19][ 20]. CTI is used in RTP [21], which uses a relative
timestamping 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 net-(RTP)/
works 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 is 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 packetiza-resources
tion 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 recon-the
structed. So a combination of ATM networks being con-signals
nection-oriented, which allows for a determination of
jitter, and ATM using fixed cell sizes, allows for the use
of NTI [22]. In 802.11, even if jitter is known in the use
of the PCF mode, the size of packets is not fixed. Given
that the exact inter-poll period depends upon whether or
not a stretching of the CP occurs, the assumption of a
constant inter-packet generation time cannot be made,
and hence NTI cannot be used. Therefore, we recom-
mend the use of a CTI scheme.

Since most of the calls starting at 802.11 LAN 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 the PCF mode, an AP controls who sends
data, but the data could go directly from mobile station
to mobile station.

The protocol stack used to carry voice frames needs to
be specified. 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 recom-mend
running voice over RTP (given the choice of CTI
timing) over LLC/ 802. 11 MAC within the 802.11 LAN
(e. g., from an 802. 11 endpoint to the voice gateway
shown in Fig. 3). The typical RTP stack calls for UDP/ IP
between RTP and the link layer protocols. However,
these layers are not needed for the intra-802.11 LAN
portion. The RTP specification [21] states that while
UDP/ IP is typically used, other lower layer protocols can
also be used.

On the question of how often to poll a voice call, the
AP could traverse its polling list partially per superframe
(e. g., poll each node once every other superframe), once
per superframe, or multiple times per superframe. In the
CBR mode, the AP polls nodes once per superframe. All
three options will be considered for the VBR mode, and
to support calls with differential delays (e. g., calls to
ATM/ IP phones as shown in Fig. 3 will require shorter
delays on the 802. 11 portion than calls to PSTN phones
or intra-AP calls).

Consider the issue of when CFPs and CPs terminate.
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 CP 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
CF-End and starts the CP, even if the CFPMaxDuration
is not exhausted (this may occur if several voice users
are silent). However, it leaves the medium idle during
the CP, even if there are no data users. This choice is
made to keep data throughput at acceptable levels.

For the CBR mode, the superframe length is fixed. The
maximum number of calls that can be admitted is deter-mined
by the superframe length. Varying the superframe
length would impact delay variations of admitted calls,
and hence this is avoided. For the VBR mode of opera-tion,
and to support calls with varying delay require-ments
for the 802.11 portion of the call, varying the
superframe length is an option. It is possible to change
the superframe length because the beacon has a field

called CFPPeriod, which is the repetition interval of
CFPs, which in turn is related to the superframe length
(as will be explained in Section III. D).

The final issue to consider is whether or not voice
packets need error correction. Our error analysis for
voice in Section IV shows that some form of error cor-rection
is needed. There are three options. First, forward
error correction (FEC) could be used to correct errors.
Second, retransmission could be used. In the down-stream
direction, the AP should resend any packet for
which it experiences an ACKTimeout. In the upstream
direction, given our assumption that all voice packets
(sent in the PCF mode) are routed through the AP, the
AP will timeout 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.

C. Control plane actions
The 802.11 specification does not describe a method
for creating and maintaining the polling list. This is con-sidered
out of scope. To ensure that not too many voice
calls are admitted to the polling list, we propose a signal-ing
protocol with an associated Connection Admission
Control (CAC) procedure. When a mobile user initiates a
voice application, a signaling message is sent to the AP
requesting to be added to the polling list.

Our proposed signaling process is a data application
for 802.11, i. e., signaling messages to initiate a voice call
and terminate it are sent using the DCF mode. A call
setup message carries the destination address of the
called mobile station. The AP maintains the number of
voice calls admitted to be less than a maximum count.
Below we describe how this maximum is determined.
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. The computation of this
reconstruction delay is also explained below. On accep-tance
of the voice call by the called party/ voice gateway,
indicated by a response to the AP, the AP places the two
802.11 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. Table 1 lists our notation.
1 Parameters

Parameter Symbol Value
Maximum duration of the superframe
stretching period)
Va ries

Beacon interval in sec Varies
Voice coding rate in Kbits/ sec 8.5
Transmission rate in Mbits/ sec 2 (FH)
and 11
(DS)

Header overheads (RTP, LLC, MAC
with WEP) in bits a

a. Reference [1] requires headers, beacons, preambles, etc., to be transmitted at
the rate of 1 Mbps to ensure that all stations can listen to these transmissions
regardless of their individual data rates.

Physical layer header size in bits
and

number of voice calls in the
CBR mode of operation
Computed

Maximum number of voice calls in the
VBR mode of operation
Computed

Minimum value of the super frame size Computed
Minimum value of the CP Computed
Minimum value of the CFP Computed
Maximum size SDU in bits
threshold size (payload) in
and

Beacon size in bits
CF-end size in bits
The SIFS interval 0.028ms
A slot time 0.050ms
Packetization delay to create one mini-
mum sized "sample"
30ms

Time to send a voice packet generated
over a superframe duration
Computed

Time to send an RTS (20 bytes) Computed
Time to send a CTS (14 bytes) Computed
Time to send an acknowledgment frame
without data (14 bytes)
Computed

T SF
T b
c
R

h 57 8 ´
P 16 8 ´
24 8 ´
N p

N s
T SF min –
T cp min –
T cfp min –
S maxSDU 2304 8 ´
f 1100 8 ´

2304 8 ´
B 40 8 ´
CF end 24 8 ´
T sifs
T slot
P min

T SF
T v

T rts
T cts
T ack

1) Computation of the maximum number of voice calls
We compute this maximum number for the two modes
of operation, CBR and VBR. In the CBR mode, to deter-TABLE
mine how much time to allocate per call, we need to
determine the maximum size of voice packets. The max-imum
interpoll time in this mode is seconds. Add to
this to capture the possibility that a a voice pack-(includes
etization completes just after a poll. Thus, the largest
voice packet size created will be 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:

(1)
To determine the maximum number of calls, we need to
find the minimum duration of the CP, and then use
minus this minimum duration for the CFP.
includes the time to minimally send one frame as speci-Maximum
fied by Section 9.3. 3.3 of [1]. Besides this minimum
time, we need to allow for the possibility of stretching as
explained in Section II. A. is the time
needed for a maximum size stretch. After the 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 II. A, all fragments and ACKs are
sent with only SIFS intervals between them. Each frag-Fragment
ment is acknowledged. is the time to send a maxi-bits
mum-sized SDU that is fragmented into fragments of
size . To accommodate the maximum number of calls,

, where (2)

(3)
(4)

(5)
where and is given by:

(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 given by (1). In the case of a stretched CP,
the CFP is foreshortened and hence the number of bea-cons
is . Thus, the maximum number of

T SF
P min

c P min T SF + ( )

T v c P min T SF + ( ) ´ h ++ ( P)4 ´ R --------------------------------------------------------------------------4T sifs + =
T SF
T cp min –

T CP stretch –

T max
f
T cp T cp min – T cp stretch – + =

T cp min – 2T sifs 2T slot 8T ack T max +++ =
T cp stretch – T rts T sifs T cts T sifs T max ++++ =

T max m – ( 1) f h P ++ R ---------------------T ack 2T sifs ++ è ø æ ö T last + =
m S maxSDU f ¤ = T last

T last S maxSDU f m – ( 1)h P ++ – R --------------------------------------------------------------------T ack 2T sifs ++ =

T v
T SF T cp – ( )T b ¤
calls that can be admitted using the CBR mode is
, where (7)

(8)
For the VBR mode of operation, we compute the max-imum
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
rate. The two models differ in the mean holding
of the two states as shown in Table 2. By admitting

more calls than , we are statistically guaranteeing that
loss will be less than some number . is given by

(9)
where is the probability that a sending end is active.
(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.

2) Computation of build-out delay
As described in Section III. B, we selected the CTI
scheme for timing, and RTP for transport. RTP uses rela-tive
timestamps. A receiver uses a build-out delay when
it reconstructs the voice signal. The build-out delay
should be as small as possible. We first determine that
the build-out delay should be the maximum possible
delay difference between two packets. For example,
the first packet took seconds (which is
unknown) and the total delay from the start of packeti-zation
to delivery at the receiver is within the range
. How long should this first packet be
held at the receiver before playout? Let's say this is as
shown in Fig. 4. Thus the total delay experienced by the
first packet is . If the second packet took

TABLE 2 Voice models
Model Mean ON period
Mean
OFF
period

Brady's model [2] 1 sec 1. 35 sec 0. 43
May and Zebo model [3] 352ms 650ms 0. 35

N p T SF T cp – T ovhd – T v -------------------------------------------=
T ovhd B P + R -------------T sifs + è ø æ ö T SF T cp – T
b
-----------------------´ CF end P + R -------------------------+ =

p
N p
e N s

1
2pN s ------------k 2N p – ( )

2N s

k è ø
æ ö p k 1 – ( p) 2N s k –

k 2N p 1 + =

s
å e £

p

d 1
d

d min d d max £ £
h

d 1 h + d 1 y +

seconds (where is known through the relative times-codec
tamp), then this packet should be delayed by sec-times
onds so that it experiences the same total delay as
the first packet. , which means the smallest
value of is equal to the maximum value of . The
maximum value of is , and hence the
build-out delay is set to the jitter. Even if , this
result holds. In this section, we determine jitter for voice
packets in our solution.

To determine jitter, we need to identify how the two
802.11 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 exam-2N
ple, 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 experi-Equation
ence a greater delay.

In the CBR mode, all calls will have the same delay.
We compute the delay in the two directions ,
and assuming that the end is placed on the
polling list before the end.

,where (10)
The best case is that a short packet is created in time
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 , where is given by (1). Propa-assume
gation delays are neglected since the radio link is short.

The upper bound is determined by assuming that a poll
just misses the creation of a voice packet ). The
end then waits for a poll (this includes the
stretching period). On the next poll, when the end
sends the packet, it is delivered immediately to the
end. The transmission time is .

Figure 4: Build-out delay
Packets sent
Packets
received

d 1

Packets
played out

h

d 1 +y
h-y

y
h y –
d 1 h +
h y –0 ³
h y
y d max d min –
y 0 <

k1 k2 ®
k2 k1 ® k1
k2

P min T v 2 -----+ D k1 k2 ® P min T SF T v 2 -----++ £ £

P min

T v 2 ¤ T v

(P min
k1 T SF
k1
k2
T v 2

In the opposite direction, , the delay will be
larger. This delay is bounded by

(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 end is . The end gets
polled sooner than the end on the second poll.
This means the time from when the end is polled to
when the end is polled is .
The transmission time adds .

The upper bound occurs when a poll just misses a
packetization ( ). This is followed by a wait of
for the next poll. This data then waits another
time to be delivered to the end on the
next superframe. The transmission time is .

Given the jitter values (maximum delay -minimum
delay) for the two directions of the voice call, the receiv-ing
end in each case can be provided a reconstruction
delay by the AP. Thus maximum total delays for the two
directions are:

and

(12)
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 can be moved up in the polling list to consoli-date
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 (unlike in the
CBR case, where the interpoll period is a maximum of
). Three factors control delay:

(i) value of
(ii) position of the call in the polling list
(iii) whether a call is polled multiple times per super-frame,
once every superframe, or once every multiple
superframes.

In fact, these three methods can be used to offer differ-

k2 k1 ®
P min T SF T cp stretch – – + D k2 k1 ® P min 2T SF + £ £

k2 T SF T cp stretch – – k1
T v 2 ¤ k2
k2
k1 T SF T cp stretch – T v 2 ¤ – –
T v 2 ¤

P min T SF
k2
T SF T v 2 ¤ – k1
T v 2 ¤

TD k1 k2 ® max D k1 k2 ® max D k1 k2 ® max D k1 k2 ® min – ( ) + =
TD k2 k1 ® max D k2 k1 ® max D k2 k1 ® max D k2 k1 ® min – ( ) + =

k

T SF
T SF
T SF

ential delays for different types of calls. For calls to
ATM/ IP endpoints, where packetized voice implies
higher delays, the 802.11 portion of the call from the
wireless user to the AP to the voice gateway needs to be
kept small. Algorithms for how to admit calls with dif-ferential
delays, and to determine reconstructions delays
in the VBR mode of operation will be presented in a later
paper.

D. Management plane
Management plane actions consist of setting MIB vari-ables
to enable the operation of the AP and the mobile
stations as needed. A few relevant MIB variables are:
dot11CFPPeriod, dot11CFPMaxDuration, and
dot11BeaconPeriod.

The dot11CFPPeriod is the value of the repetition
interval (superframe). Section 9. 3. 3. 3 of [1] specifies the
minimum CFP period as:

, (13)

where is the time to send one voice packet and
receive a response. Adding this to shown in
(2), yields

.( 14)

The superframe duration should be chosen so that
. The CFP repetition interval
dot11CFPPeriod is advertised to be ,
so that the AP can try to gain the medium for the CFP at
the end of the CFP repetition interval. In other words,
includes the stretching time.

The maximum size of the superframe is a trade-off
between the number of calls the network is being engi-neered
for and voice delay constraints. (We'll provide
numerical values in the analysis section.)

Having set the CFPPeriod, dot11CFPMaxDuration, is
set to the CFPPeriod minus .

The dot11BeaconPeriod, the interval between consec-utive
beacons transmitted by the AP, is set to equal the
dot11CFPPeriod variable. This limits the number of
beacons generated within a CFP to 1 (i. e., at the start),
reducing the Beacon overhead.

IV. ANALYSIS
In this section, we determine numerical values for the
various parameters set through the management plane
(Section A), and the maximum call count used in the
CAC algorithm at the AP (Section B). Sections C and D

T cfp min – T B T CF end – 3T sifs T v 2 ¤ ( ) +++ =
T v 2 ¤
T cp min –

T SF min – T cfp min – T cp min – + =

T SF T SF min – ³
T SF T cp stretch – –

T SF

T cp min – 8

describe a delay analysis and a loss analysis, respec-tively.
A. MIB variable numerical values
Table 3 shows the values of certain parameters needed
for MIB variable settings (see Section III. D) These are
determined for both the 2 Mbps and 11 Mbps data rates,
from (3), (4) and (14).

B. Numerical values for maximum number of calls
Fig. 5 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)). 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 maxi-mum
number of voice calls that can be admitted at the
relatively large values of fragment sizes used in Fig. 5.

Table 4 compares the maximum number of calls
admissible in the CBR mode and VBR mode ( )
using both Brady's and May and Zebo's voice models
for superframes of 75 and 90 ms. With these superframe

TABLE 3 Val ues i n ms
Data rate (R)
Mbps

2 11. 9 10.7 14.9
11 4.4 3. 2 5.8

T cp min – T cp stretch – T SF min –

Figure 5: Maximum number of voice calls
N p ( ) N s

sizes, our assumption that a packet should be dropped if
not served in a superframe holds. The loss rate, , in (9),
is assumed to be 10 -3 . The numbers are optimistic

since delays are not considered in (9). Since the VBR
mode exploits silences, the maximum size of a voice
packet is larger than assumed in (1). We
also note that while the maximum number of calls that
can be supported in the VBR mode is about double that
can be supported in CBR mode, delays will be larger in
the VBR mode.

C. Delay analysis
The maximum delay values determined using (12) are

plotted in Fig. 6. Delays for both directions
and at both LAN rates, 2 Mbps and 11 Mbps,
are shown. Under the CBR assumption, since all voice
calls experience the same delay, differential delays can-not
be supported. This means that in this mode, a small
enough should be chosen to meet the delay require-ments
of calls to users on other networks. However, this

TABLE 4 Maximum number of voice calls: B (Brady's model)
and MZ (May and Zebo model)

Tsf
(ms)

FH (2 Mbps) DS (11 Mbps)

(B) (MZ) (B) (MZ)
75 12 22 27 22 41 51
90 14 26 32 27 52 65

e N
s

N p N s N s N p N s N s

c T SF P min + ( )

Figure 6: Total delay
k1 k2 ®
k2 k1 ®

T SF

will decrease the number of voice calls that can be sup-ported,
and will also affect data throughput. For exam-ple,
if a superframe size of 90ms is used, then total
delays of 121 and 303 msec will be experienced in the
and directions, respectively, for the
802.11 portion of the voice call (on a 11Mbps LAN).

D. Loss analysis
802.11 MAC protocol supports retransmission to
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 Fig. 7 [23]. The parameters for the two models
are given in Table 5. The first burst error model used to

characterize fading is from [23]. 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 hold-ing
state during a packet transmit time.

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

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

TABLE 5 Parameters for burst error models
Model BER G BER B a l
1 10 -10 10 -5 10/ sec 30/ sec
2 10 -4 10 -2 20/ sec 10/ sec

k1 k2 ® k2 k1 ®

Figure 7: Model of a wireless channel
Good Bad
(G) (B)

l
a

BERB BER G
Bit Error Rate

v
T v pkt – v ++ ( hP) R --------------------------=

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 dis-The
tribution and by neglecting propagation delays, the prob-handle
abilities of the three cases can be derived to be:

(16)

(17)
,( 18)
where and are the probabilities of starting a
packet transmission when the channel is in the good or
the bad state, respectively, and are given by:

.( 19)
The probabilities of a packet error in the three cases
are approximated by:

(20)

(21)
(22)
Combining the probabilities of the three cases, given
by (16) to (18), with the probability of packet errors in
the three cases, given by (20) to (22), yields the total
packet error probability as

(23)

where a worst-case error rate is assumed if case 3 hap-its
pens, i. e., that all bits are subject to .

In the CBR mode, the largest-sized voice packets are:

bits. (24)

This upper bound of is plotted against in Fig.
8 for error models 1 and 2. The 11Mbps network experi-
ences a higher packet error rate even though the packet
transmission time can be expected to be shorter owing to
the higher data rate. This is because DS packets have a
larger preamble than FH packets.

For a 90 ms , a packet error rate of approximately
10 -2 and 0.44 for model 1 and model 2, respectively, are

p case1 p G P G T v pkt – > ( ) a l a + -------------e v pkt – –lT ==
p case2 p B P B T v pkt – > ( ) l l a + -------------e v pkt – –aT ==
p case3 1 p case1 p case2 – – =
p G p B

p G a l a + -------------= p B l l a + -------------=

e case1 1 1BER G – ( ) v ++ ( hP) – =
e case2 1 1BER B – ( ) v ++ ( hP) – =
e case3 e case2 £

p e p case1 e case1 p case2 e case2 p case3 e case2 ++ ( ) £
BER B

v cT SF P min + ( ) =
p e T SF

T SF

observed from the graphs. For voice, with a loss toler-ance
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 III. B.

V. CONCLUSIONS
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 guar-antees.
The simplest mode in which to run the LAN is a
Constant Bit Rate (CBR) mode. In this mode, build-out
delays at receivers can be computed. In this mode, since
all calls experience the same delay, inter-poll periods
should be chosen for the most stringent delay require-ment;
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.

ACKNOWLEDGMENTS
We thank Amy Wang, Symbol Tech., Prof. Shiv Pan-war,
Prof. Henry Bertoni and Ramesh Badri, Polytechnic
University, for their help with this work.

REFERENCES
[1] ISO/ IEC and IEEE Draft International Standards, "Part 11:
Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications," ISO/ IEC 8802-11, IEEE
P802. 11/ D10, Jan. 1999.
[2] P. Brady, "A Model for Generating On-Off Speech Patterns in
Two-Way Conversation," Bell Syst. Tech. Journal, vol. 48, no.
7, pp. 2245-2272, Sept. 1969.
[3] C. E. May and T. J. Zebo, "A summary of speech statistics mea-sured
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

Figure 8: Packet error rates
Transmission Time" G. 114, Feb. 1996.
[5] A. 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 com-munications",
Proc. 39th IEEE Vehicular Technology Confer-ence,
pp. 701-6, 1988.
[7] A. 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 Communica-tions,
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] I. Akyildiz, J. McNair, L. Martorell, R. Puigjaner, Y. Yesha,
"Medium access control protocols for multimedia traffic in
wireless networks," IEEE Net. Mag., vol. 13, no. 4, pp. 39-47,
Jul./ Aug. 1999.
[11] J. Sanchez, R. Martinez, M. Marcellin, "A survey of MAC pro-tocols
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 in-door
wireless communications", Proc. IEEE Intl. Conf. on Se-lected
Topics in Wireless Communications, pp. 406-8, 1992.
[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 Communi-cations
(PIMRC), pp. 648-52, Sep. 1995.
[15] B. Crow, I. Widjaja, J. Kim, P. Sakai, "Investigation of the
IEEE 802.11 medium access control (MAC) sublayer func-tions",
Proc. Infocom, pp. 126-33, Apr. 1997
[16] B. 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 Communi-cations
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 Pro-tocols
for Packet Voice," IEEE JSAC, vol. 7, no. 1, June. 1989,
pp. 632-643.
[20] W. Montgomery, "Techniques for packet voice synchroniza-tion,"
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] E. Gilbert, "Capacity of a Burst Noise Channel," Bell Syst.
Tech. J., vol. 39, Sept. 1960, pp. 1253-66. 11