Call Admission Control in IEEE 802.11e EDCA-based WLANs
(Initial Steps)
Boris Bellalta1 , Michela Meo2 , Miquel Oliver1
(1) Universitat Pompeu Fabra
P. Circumval·lació, 8, 08003 Barcelona, Spain
Tel: +34 93 542 18 95
Email: boris.bellalta@upf.edu
(2) Politecnico di Torino
TD(06)012
The 5th COST 290 Management Committee Meeting
TNO Telecom / University of Twente, The Netherlands, February 9-10, 2006
Abstract
The random access MAC protocol of WLANs is a key aspect in the actual rapid deployment of
WLANs. However, the lack of a hard centralized control of the transmission resources, complicating an
efficient implementation of QoS mechanisms without losing the inherent advantages of the distributed
access scheme. To solve this difficulties, the EDCA IEEE 802.11e proposal has been released but, critical
aspects like admission control and resource scheduling are to be solved and therefore, require further
research to find optimal parameter configurations.
Keywords: IEEE 802.11e, WLAN, QoS, Model, Admission Control
COST 290: Traffic and QoS Management in Wireless Multimedia Networks
http://www.cost290.org
1
1
Introduction
The increasing popularity of Wireless Local Area Networks (WLANs) based on the IEEE 802.11 [1] technology, due to the ease in installing access facilities and to the affordable price of the equipments, is pushing
operators to deploy WLANs as access networks to their services. However, the limitations of this technology, such as the still limited radio resources, the poor channel quality depending on relative position of
Mobile Nodes (MN), the interference from hidden terminals and the anomaly observed when MNs transmit
at different speeds [2], make it difficult to cope with the need to provide a variety of services with different
characteristics in terms of QoS requirements. Indeed, current WLAN networks provide best-effort services
without any QoS guarantees. Due to the higher bandwidth provided, multimedia services such video and
voice streaming can perform well under low load conditions but, when traffic intensity increases, the delay
and bandwidth of streaming flows are severely affected.
In particular, services can be distinguished in two classes based on the mechanisms employed at the
transport layer: i) elastic flows, usually adopted to deliver data services such as file transfer applications,
correspond to traffic carried by TCP and TCP-like protocols, that adapt the traffic generation rate to the
network working conditions, attempting in this way to reduce network congestion; ii) streaming flows, adopted
by multi-media applications, tend to generate traffic unaware and independently of the network conditions.
Some possible solutions for guaranteeing acceptable QoS levels consist in performing call admission control
(CAC). By properly choosing the MAC defined parameters, QoS levels for accepted flows can be reasonably
guaranteed. For a related work on the area, refer to [3].
In this report, first we introduce the EDCA mode of operation of the IEEE 802.11e specification [4]. In
order to estimate its performance, we propose a simple but practical analytical model which allow us to
evaluate all protocol enhancements such as the transmission opportunity (TXOP), the use of different interframe spaces (AIFS) and different values for the backoff procedure. Once the MAC protocol is validated,
we analyze the performance of VoIP calls and show the lack of reliability when TCP flows and VoIP calls
coexist in the same cell. A Continuous Time Markov Chain (CTMC) is used to include the user behavior
(flow arrival and departures) for both VoIP calls and TCP uplink/downlink flows which is used to evaluate
the impact of several parameter configurations in the overall system performance.
2
A HotSpot Wireless Scenario
A wireless Cell (or hot-spot) is the coverage area provided by a single access point (in [1] it is referred as
a Basic Service Set, BSS). The coverage area is the geographical area where both the access point (AP)
and the mobile stations can communicate using the radio channel with an acceptable minimum quality; this
quality can be measured in terms of SNR and other derived metrics such as the Frame Error Ratio (FER).
2
http://heim.ifi.uio.no/~paalee/
Parameter
Rdata
DIFS
SIFS
SLOT (σ)
EIFS
RTS
MAC header
PLCP preamble
Retry Limit (R)
Value
2 M bps
50 µs
10 µs
20 µs
364 µs
160 bits @ Rbasic
240 bits @ Rdata
144 bits @ Rbasic
7
Parameter
Rbasic
CWmin
CWmax
m
ACK
CTS
MAC FCS
PLCP header
Q (Queue length)
Value
1 M bps
32
1024
5
112 bits @ Rbasic
112 bits @ Rbasic
32 bits @ Rdata
48 bits @ Rbasic
20 packets
Table 1: System parameters of the IEEE 802.11b specification [1]
An Extended Service Set (ESS) contains multiple access points and their coverage areas. All or part of these
coverage areas can overlap, so that a mobile station can select the access point to use; we call these areas
reassociation or handoff areas.
Typical scenarios with this configuration are found in public areas (like cafeterias, parks, airports) where
users can access the Internet from their notebooks or PDAs; company/university buildings where workers/students use WLAN networks to communicate through the email service, message applications or voice
over IP; individual users at their homes, etc. Anyway, in all these scenarios, the WLAN technology provides
a certain grade of mobility and a broadband access to Internet at very low cost.
In this work, we consider a single BSS with an AP providing access to a fixed network to n mobile nodes
(then we omit the arrival of handoff flows). Each node has a traffic profile specifying its basic configuration
parameters, i.e., bandwidth, packet arrival rate, expected frame length, etc. The mobile nodes and the access
point use the EDCA (Enhanced Distributed Channel Access) of the IEEE 802.11e MAC and the DSSS PHY
specifications in the 2.4 GHz band [1].
2.1
System parameters
The system parameters used by the legacy DCF (Distributed Coordination Function) are reported in Table
1. We assume ideal channel conditions, i.e., no packet is lost due to channel errors or the hidden terminal
phenomenon.
3
IEEE 802.11e EDCA
The EDCA mode of operation of the IEEE 802.11e medium access control implements a mapping function
which classify each traffic flow in an Access Category (AC). Four AC are defined, each one associated to one
MAC transmission queue. Each access category has its own MAC parameters and behaves independently of
others. Letting ACj the access category j, the basic MAC parameters of each access category are labeled
as: Arbitration Inter-frame Space AIF Sj , Minimum Contention Window CWmin,j , Maximum Contention
3
Window increments mj and Transmission Opportunity T XOPj . The default values of each parameter are
reported in Table 2.
For a generic node i, according to the basic access (BA) mechanism, when a node has no packets to
transmit and receives a packet from the network layer, it is classified in an ACi,j and the node starts to
sense the channel to determine its state, that can be either busy or free. If the channel is detected busy, the
node waits until the channel is released. When the channel is detected free for a period of time larger than
the AIF Si,j duration, a new backoff instance is generated. A backoff instance consists on a counter set to a
random value each time it is generated. The random value is picked from a uniform distribution in the range
¡
¢
CWi,j (k) = [0, min 2k CWmin,i,j − 1, 2mi,j CWmin,i,j − 1 ], where k is the current attempt to transmit the
packet. For each packet to be transmitted, k is initially set to 0 and it is increased by one at each failed
transmission until a maximum number of retransmissions, called Retry Limit, is reached, and the packet is
dropped. The counter is decreased by one for each time-slot σ in which the channel is sensed free, and, when
the countdown reaches zero, the node starts the packet transmission on the channel. If during the backoff
countdown the channel is sensed busy, the backoff is suspended until the channel is detected free again.
The AIF Si,j value is computed using the DIF S value and a non-negative integer Aj specific for each AC:
AIF Si,j = DIF S + Aj σ 1 . Once a node gets the channel, it can transmit up to T XOPi,j M P DU packets.
This limit is expressed in time units (ms) and corresponds to all consecutive time a node can use to transmit
few (large) or several (small) packets. A channel collision occurs if two nodes transmit at the same time, i.e.,
a backoff instance from both nodes reach 0 at the same time. A virtual collision occurs if two AC of the same
node transmit at the same time. In this case, the collided packet of the AC with higher priority is transmitted
to the channel while the other/s start the retransmission procedure. After the data packet is transmitted
to the channel by the sender, the receiver waits for a SIFS (Short Inter-Frame Spacing) time and sends a
MAC layer ACK to acknowledge the correct reception of the data packet. In the case the sender does not
receive the ACK frame, it starts the retransmission procedure. After discarding or successfully transmitting
a packet, if more packets are ready to be transmitted, the node starts the transmission procedure again.
Otherwise, it waits for a new packet from the network layer. Another feature of the EDCA is the use of the
different ACK policies (no ACK transmission or ACKs aggregation) which also can be used to improve the
system performance.
Alternative to the BA mechanism, nodes can employ a RTS/CTS protocol to access the channel, so as to
reduce the hidden terminal effect.
1 In fact, the correct timing of AIF S
i,j is AIF Si,j = 3 · SIF S + Aj σ, but we use previous definition for coherence with the
results presented in this report.
4
AC
0 (Background)
1 (Best effort)
2 (Video)
3 (Voice)
Aj
5
1
0
0
T XOPlimit (ms)
0
0
6.016
3.264
CWmin,j
32
32
16
8
CWmax,j
1024
1024
32
16
Table 2: Default EDCA Parameter Set element parameter values
3.1
Frame Durations
When a node transmits a frame, two possible events can occur: a collision or a successful transmission. The
duration of both events depends on the employed access mechanism. The successful transmission duration
for the BA and the RTS/CTS mechanisms, are, respectively, given by:
Tsba =
P HYH
M ACH + Ldata + M ACF CS
P HYH
LACK
+
+ SIF S +
+
+ DIF S
Rbasic
Rdata
Rbasic
Rbasic
(1)
P HYH
RT S
P HYH
CT S
+
+ SIF S +
+
+ SIF S + Tsba
Rbasic
Rbasic
Rbasic
Rbasic
(2)
Tsrts =
with
P HYH = P LCP preamble + P LCP header
(3)
For the basic access mechanism, the duration of a collision is equal to the maximum successful transmission
duration of the colliding frames, but for the RTS/CTS mechanism the duration of a collision is constant and
equal to
Tcrts =
P HYH
RT S
+
+ EIF S
Rbasic
Rbasic
(4)
The additional overhead of the RTS/CTS access compensates with a low collision duration.
The duration of a successful transmission with T XOPj packets transmitted in a burst is:


 TsT XOPj ,ba = T XOPj · T ba + (T XOPj − 1) · SIF S + DIF S,
s
T
XOP
,rts

j
 Ts
= RT S + SIF S + CT S + SIF S + T XOPj · Tsba + (T XOPj − 1) · SIF S + DIF S,
(5)
Finally, using the TXOP option, a collision has the same duration than using the standard DCF (only
collides the first frame of the burst).
5
4
A Model of the IEEE 802.11e EDCA
In this section, a user-centric model of the EDCA function of the 802.11 MAC layer is presented. We
approximate each mobile node by a finite length queue with bulk service time and network-dependent service
time. We assume that each mobile node carries a single traffic flow of category ACj (or equivalently, each
node i only has active at the same time one ACj ). For the sake of simplicity, henceforth we omit the subscript
j as a single AC is considered to be active in each MN.
4.1
A mobile node
Packets with average length Li arrive to node i with rate βi . Both the time between packet arrivals and
the service time are assumed to be exponentially distributed. Therefore, a mobile node (the AP included) is
modeled by an M/M [T XOPi ] /1/Qi queue with Qi as the queue length measured in packets and bulk service
time (Figure 1). The steady state probability of the presence of q packets in the queue is denoted by πq,i .
The bulk service time is used to approximate the TXOP (Transmission Opportunity) option of the EDCA.
The offered traffic load to the MAC layer, the queue utilization and the expected throughput for node i are
νi , ρi and Si respectively.

PQi


νi = βi k=0
πk,i Xik ,



PQi
πk,i = 1 − π0,i ,
ρi = k=1



P
P

T XOPi ·Li
 Si = T XOPi πq,i k·Lki + Qi
T XOPi
k=T XOPi +1 πq,i
k=1
X
(6)
Xi
i
The aim to model each mobile node using an M/M [T XOPi ] /1/Qi queue allows us to obtain simple expressions to measure the quality of the service observed by a node in terms of blocking probability, average
queue length and average transmission delay (including the service time).



Pb,i = πQi ,i ,



PQi
EQi = k=1
k · πk,i ,




EQi
 EDi =
λi (1−Pb,i )
(7)
The probability to loose a packet is the probability that the packet is discarded at the queue entrance due to
overflow or dropped at the MAC layer because the number of retransmissions have exceeded the retry limit,
Ri . Then, a burst loss occur with probability
PL,i = Pb,i + (1 − Pb,i )Pd,i
where Pd,i is the probability that a packet is dropped at the MAC layer.
6
(8)
βi
βi
0
1
µ
1
i
βi
2
βi
3
βi
4
βi
βi
Qi-1
Qi
µi2
µi3
µi3
µi3
µi3
Figure 1: M/M [T XOPi ] /1/Qi , T XOPi = 3
4.2
The MAC protocol
A node with a packet ready to be transmitted starts a backoff instance. Letting AEBi be the average number
of backoff slots at each transmission attempt by node i, the steady state probability that the node transmits
in a random slot given that a packet is ready in its transmission queue can be computed from
τi =
E[P r(Qi (t) > 0)]
ρi
=
AEBi + 1
AEBi + 1
(9)
Node i transmission collides if any other node also transmits in the same slot. Then, the conditional collision
probability for node i is
pi = 1 −
Y
(1 − τj )
(10)
j6=i
In order to compute the average number of backoff slots selected at each transmission attempt, EBi ,
two different approaches are found in the literature: a stochastic (Markovian) approach [5] and an average
analysis [6]. Expressions found in both papers are different but numerically equal. For simplicity, we choose
to use the expression of [6], then EBi is computed as
EBi =
1 − pi − pi (2pi )mi CWmin,i
1
−
1 − 2pi
2
2
(11)
The effect of the Retry Limit Ri is considered in [7]. However, for operative values of pi < 0.4, the
effect of Ri on the average backoff time at each attempt is almost negligible. Using the conditional collision
probability, the dropping probability at the MAC layer is given by the probability that a packet collides Ri
i
times, Pd,i = pR
i .
Note that AEBi ≥ EBi due to AIF Si ≥ DIF S, i.e., Ai ≥ 0. To compute the value AEBi we use a
similar approach as in [8]. We take into consideration that the number of transmissions observed by a node
during its backoff is ptr,i · EBi , which implies an extra number of slots that the node has to wait equal to
7
ptr,i · EBi · Ai , then
AEBi = (EBi + Ai ) + ptr,i · EBi · Ai
(12)
where ptr,i is the probability that at least another node transmits in a given slot
ptr,i = 1 −
Y
(1 − τj )
(13)
j6=i
The service time, i.e., the time interval from the instant in which a packet enters in service until it is
completely transmitted or discarded, is given by,
³
´
ba||rts
T XOPi ,ba||rts
+ AEBi αi + Ts,i
XiT XOPi = (M − 1) AEBi αi + ETc,i
(14)
where M is the average number of transmissions, αi is the average slot duration and ETc,i is the average
duration of a collision of node i. We approximate the value of ETc,i by,


 ET ba ≈
c,i
P
j6=i
ba
ba
τj max(Ts,i
,Ts,j
)
P
j6=i τj
(15)

rts
 ETc,i
= Tcrts
where we neglect the fact that more than two packets collide simultaneously. Note that if the RTS/CTS
rts
access scheme is used, ETc,i
is constant and equal for all nodes. The average number of transmissions that
a packet undergoes is computed under the decoupling assumption as,
M=
i +1
1 − pR
i
1 − pi
(16)
The departure rates of each state for the M/M [T XOP ] /1/Qi,j queue depend of the T XOPi,j parameter
and the instantaneous queue occupation, si , in packets.


 µsi = 1/X si ,
si < T XOPi ;
i
i

 µTi XOPi = 1/XiT XOPi , si ≥ T XOPi .
(17)
A node frozes its backoff counter every time the channel is sensed busy and releases it after the channel
is sensed free for a DIF S period. Therefore, the time between two backoff counter decrements is a random
variable which depends on the behavior of the other nodes. By letting αi be the average time between two
backoff counter decrements, or equivalently, the average slot duration, we have
T XOPi ,ba||rts,∗
αi = pe,i σ + ps,i (ETs,i
8
ba||rts,∗
+ σ) + pc,i (ETc,i
+ σ)
(18)
Traffic Flow
Sat. (E1)
Sat. (E2)
Scenario 1
Bandwidth Frame Length
max. avail.
700 B
max. avail.
1500 B
Scenario 2
Bandwidth Frame Length
max. avail.
1500 B
100 Kbps
400 B
Traffic Flow
Sat. (E1)
Unsat. (S1)
Table 3: Traffic profiles.
T XOPi,j ,ba||rts,∗
where ETs,i
T XOPi,j ,ba||rts,∗
and ETc,i
are the average durations of an observed successful
T XOPi,j ,ba||rts,∗
transmission or a collision for node i when it is performing a backoff instance. To compute ETc,i
we consider that the probability that more than two stations collide can be neglected, then


ba,∗
 ETc,i
≈
P
P
j6=i

 ET rts,∗ = T rts
c
c,i
Q
ba
ba
max(Ts,j
,Ts,k
)(τj τk u6={j,k,i} (1−τu ))
Q
k>j,k6=i (τj τk
u6={j,k,i} (1−τu ))
k>j,k6=i
P
P
j6=i
(19)
and
´
(1
−
τ
)
u
u6={i,j}
³ Q
´
τ
(1
−
τ
)
j
u
j6=i
u6={i,j}
P
T XOPj ,ba||rts,∗
ETs,i
≈
T XOPj ,ba||rts
j6=i Ts,j
P
³
τj
Q
(20)
The probabilities pe,i , ps,i and pc,i are related to the channel status in a given slot when a node is in
backoff. pe,i is the probability that a slot is observed empty, ps,i the probability that in a slot a successful
transmission occurs and pc,i is the probability that a collision occurs. Note that at the end of a successful
transmission or a collision we add the duration of an empty slot, since the backoff counter is only decreased
after the channel is sensed empty for the full duration of a slot. These channel probabilities can be computed
as
pe,i =
Y
(1 − τj )
j6=i
ps,i =
X
z6=i
τz
Y
(1 − τj )
pc,i = 1 − pe,i − ps,i
(21)
j6=z6=i
Due to the dependence of previous expressions on the queue utilization of each node, ρi , and the fact that
(9) and (10) form a set of non-linear equations, we have to use iterative numerical techniques to solve the
model.
4.3
Model Validation
In order to validate the model, we have considered two single-hop scenarios with traffic flows whose characteristics are summarized in Table 3. The network comprises n nodes, each node uses the BA access scheme
and carries a single traffic flow. We refer to S1 to unsaturated (streaming) flows and we use E1 (E2) to refer
to saturated (elastic) flows. Analytical results are compared against simulations performed using a detailed
simulator of the EDCA IEEE 802.11e MAC protocol built using the COST (Component Oriented Simulation
Toolkit) simulation engine [9].
9
In Figure 2 (Scenario 1) we plot the aggregate throughput for one E1 flows when the number of E2
flows increase. The goal of the different parameter settings is to provide more bandwidth to the E1 flow
and protect it from E2 flows. Similar experiment is carried in Scenario 2 (Figure 3). In this case we fix the
number of elastic flows E1 to 4 and increase the number of streaming flows S1. The goal is the same than
in previous scenario: to provide protection to S1 flows respect to the E1 flows. Note how with a properly
parameter tuning we can achieve the goal and then improve the system performance. Anyway, these results
allow to validate the model as both simulation and analytical outputs match very well.
6
2
6
x 10
2
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
2
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
1.8
1.6
1.4
1.4
1.2
1.2
1.2
bps
1.6
1.4
1
1
0.8
0.8
0.6
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
0
0
2
3
4
5
6
7
8
9
10
1
2
3
4
5
E2 Flows
8
9
0
10
2
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
2
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
1.8
1.4
1.2
1.2
1
bps
1.4
1.2
bps
1.4
1
0.8
0.8
0.6
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
5
6
E2 Flows
(d)
7
8
9
10
0
1
6
7
8
9
10
2
3
4
5
6
7
8
E2 Flows
(e)
9
x 10
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
1
0.8
4
5
1.8
1.6
3
4
6
x 10
1.6
2
3
(c)
1.6
1
2
E2 Flows
6
x 10
1.8
0
1
(b)
6
bps
7
E2 Flows
(a)
2
6
E1 − Sim
E1 − Model
E2 − Sim
E2 − Model
1
0.8
1
x 10
1.8
1.6
bps
bps
1.8
6
x 10
10
0
1
2
3
4
5
6
7
8
9
10
E2 Flows
(f)
Figure 2: (Scenario 1) Aggregate Throughput for E1 and E2 (a) IEEE 802.11b parameters (b) T XOPE1 = 4
(c) AIF SE2 = 3 (d) CWmin,E2 = 64 (e) T XOPE1 = 4 and AIF SE2 = 3 (f) T XOPE1 = 4 and CWmin,E2 =
64
5
Voice over IP performance in WLAN
Voice communication using WLAN technology as access network could be a promising alternative to traditional cellular networks (2G, 3G). Currently, roaming problems between WLAN coverage areas have to be
solved to provide a continuous service to the user. However, novel proposals to interconnect and manage
WLAN cells using common fixed infrastructure operators are yet a promising reality [10]. Moreover, three
10
6
2
6
x 10
2
S1 − Sim
E1 − Model
E1 − Sim
E1 − Model
2
S1 − Sim
E1 − Model
E1 − Sim
E1 − Model
1.8
1.6
1.4
1.4
1.4
1.2
1.2
1.2
bps
1.6
1
1
0.8
0.8
0.6
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
1
2
3
4
5
6
7
8
9
0
10
1
2
3
4
5
S1 Flows
8
9
0
10
2
S1 − Sim
E1 − Model
E1 − Sim
E1 − Model
1.8
2
S1 − Sim
S1 − Model
E1 − Sim
E1 − Model
1.8
1.2
1.2
1
bps
1.4
1.2
bps
1.6
1.4
1
0.8
0.8
0.6
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
0
0
6
7
8
9
10
1
6
7
8
9
10
2
S1 Flows
(d)
3
4
5
6
7
8
9
x 10
S1 − Sim
S1 − Model
E1 − Sim
E1 − Model
1
0.8
5
5
1.8
1.6
4
4
6
x 10
1.4
3
3
(c)
1.6
2
2
S1 Flows
6
x 10
1
1
(b)
6
bps
7
S1 Flows
(a)
2
6
S1 − Sim
E1 − Model
E1 − Sim
E1 − Model
1
0.8
0
x 10
1.8
1.6
bps
bps
1.8
6
x 10
10
S1 Flows
(e)
0
1
2
3
4
5
6
7
8
9
10
S1 Flows
(f)
Figure 3: (Scenario 2) Aggregate Throughput for S1 and E1 (a) IEEE 802.11b parameters (b) T XOPS1 = 4
(c) AIF SE1 = 3 (d) CWmin,E1 = 64 (e) T XOPS1 = 4 and AIF SE1 = 3 (f) T XOPS1 = 4 and CWmin,E1 =
64
major technological issues of the IEEE 802.11 MAC protocol itself have to be solved or improved to achieve
an efficient use of the transmission resources.
1. High protocol overheads.
2. Unfairness between uplink and downlink streams.
3. Fast VoIP degradation in presence of TCP flows.
A criterium to determine the maximum number of VoIP calls that can be transported by a network (also
called VoIP capacity) given the desired voice quality in terms of bandwidth, delay, losses, can be found in
[11]. For a good quality, the average delay have to be less than 150 ms with losses less than 3%. A medium
quality is achieved with delays between 150 and 400 ms and packet losses less than 7%. Finally, a poor voice
quality corresponds to delays higher than 400 ms and losses higher than 7%. Considering that the WLAN
is only one hop of the whole path between the two end points, for a conservative good design, quality target
should be set to at least one-third of the maximum recommended values.
11
Codec
Max number of calls: Cvoip (no contention)
Efficiency (no contention: η, η = Cvoip · Bvoice /RDAT A )
Max number of calls (contention)
G.711
4
12.8%
4
G.723.1
9/9
2.37%/2.85%
7/7
G.726-32
5
8%
4
G.729
6
2.4%
5
Table 4: VoIP efficiency over WLAN
5.1
Protocol Overheads
Taking into account the parameters defined by the IEEE 802.11b standard [1], summarized in Table 1, we
can compute the maximum number of voice calls without contention, i.e., the channel is ideally shared among
voice calls, and with contention, see results in Table 4. From the results, we can conclude that the contention
to access the channel reduces the maximum number of calls but it is not the main limiting factor. It is clear
that the main problem is the large overhead introduced by the higher layer protocols. A technique to solve
this situation is header compression such as ROHC (RObust Header Compression, RFC 3243).
5.2
Unfairness
As the access point carries the same data as the whole set of the mobile nodes, it has to attempt to transmit
n times more than each mobile node. Therefore, it is desirable that the transmission attempts of the AP
are n times greater than the transmission attempts of a single mobile node, or equivalently τd = nτu , to
achieve a fair access to the channel (each node access to the channel proportionally to the traffic volume it
has to send). This can be achieved in two ways: increasing the number of attempts of the AP with respect
to mobile nodes (modifying the BEB parameters) or allowing to transmit to the AP more data each time it
access the channel (using larger TXOP values).
5.3
Interaction with TCP flows
As the AP queue is shared by all downlink streams, the VoIP packets have to compete for the buffer space
with all the other flows, that can be streaming (UDP) or elastic (TCP) flows (both data and ACKs destined
to a mobile node). TCP downlink traffic tends to saturate the MAC queue [12] which cause high losses
to the VoIP flows. Moreover, any uplink flows reduce, proportionally to its bandwidth, the transmission
opportunities gained by the AP. The negative effect over the downlink traffic is increased if these uplink flows
are TCP-based which also tend to saturate the mobile nodes queue [13].
The negative influence of the TCP traffic is clearly shown in Table 5. Note the fast degradation of the
VoIP throughput with TCP downlink flows and the inoperability of any VoIP call with just a single TCP
uplink flow. It is also interesting to observe that, when the AP queue is saturated with VoIP traffic, the
interaction with TCP traffic is reduced due to the starvation of TCP flows. Therefore, the presence of TCP
traffic in both the downlink (buffer losses) and the uplink (AP starvation) leads to low performance of VoIP
12
No TCP flows
VoIP calls (G.729)
1
2
3
4
5
6
0.024
0.048
0.072
0.096
0.120
0.127
TCP Downlink
1
5
10
0.023 0.023 0.022
0.047 0.045 0.043
0.071 0.066 0.062
0.094 0.088 0.081
0.114 0.106 0.102
0.126 0.126 0.118
TCP Uplink
1
5
10
0.018 0.008 0.006
0.026 0.014 0.014
0.029 0.023 0.021
0.030 0.029 0.031
0.029 0.030 0.028
0.127 0.027 0.016
Table 5: Downlink throughput (at MAC layer) for VoIP calls in presence of TCP flows (Mbps)
calls. These problems have to be solved in order to deploy a successful VoIP service over WLAN.
In the downlink, a simple classification/prioritization scheme can be used (using the different Access
Categories (AC) defined in the EDCA [4] or, for example using the dual queue proposed in [14]) where the
TCP and UDP packets occupy separated buffers with priority for the VoIP packets. However, the main
problem is with the TCP uplink flows because each node acts independently from the others. The only
possible solution is setting different MAC parameters (such as AIF S [15], CWmin [16], T XOP [17]) to each
mobile node in order to reduce the interaction of these TCP flows on the VoIP calls. Another possibility is
to apply some ACK policies such as No ACK or Block ACK [18].
6
Call Admission Control
With the goal to solve the performance problems previously exposed about the interaction between TCP and
UDP traffic, we propose an admission control scheme which is capable to differentiate between streaming and
elastic traffic and, at the same time, between uplink and downlink flows, providing an acceptable grade of
service for streaming flows (VoIP).
6.1
CAC Architecture
The call admission control entity is located at the AP and is based in the standard procedure defined in
[4]. When an application wants to use the cell resources it sends an ADDT S (Add Traffic Specification)
request packet to the AP with the traffic profile required by the flow. Using the information provided by
the application, the call admission control decides if the new state of the network is feasible. If so, it sends
a positive response to the request (ADDTS response), with the MN parameter configuration which makes
possible to accept the new flow. Otherwise, it sends a negative response and the new flow is rejected,
preserving the grade of service of the active flows already in the system.
To differentiate TCP and UDP downstream flows, the AP uses different AC for each class, where UDP
packets are isolated from TCP packets and with service prioritization for the UDP queue given by a short
AIF S. Moreover, the upstream flows are differentiated by setting different MAC layer parameters: CWmin ,
13
AIF S or T XOP for each flow.
6.1.1
Different ACj (queues) at Access Point
To differentiate between downstream TCP and UDP packets we use different ACj to VoIP and TCP flows,
given priority to the UDP AC, called ACudp . We refer with ρs,d to the UDP queue utilization and with ρe,d
to the TCP (ACtcp ) queue utilization, respectively. To simplify the analysis, we assume that TCP packets
are served only when the UDP queue is empty, then the probability to transmit a downstream TCP packet
is 1 − ρs,d . Note that, since the upstream feedback traffic is proportional to the downstream TCP traffic,
we can assume a minimal impact of uplink TCP ACKs over the UDP packets. Clearly, the elastic flows
can suffer starvation when ρs,d ≈ 1. However, this can be solved by setting a maximum ρth
s,d value, e.g.,
th
ρth
s,d = 0.8, which assures that at least the 1 − ρs,d of the transmissions are for TCP downstream flows (or
setting properly the different MAC parameters of each ACj ).
6.1.2
Uplink differentiation via different values of CWmin
In order to differentiate the VoIP flows with respect to the TCP uplink flows (which cause a major performance
degradation), we propose to use different CWmin values that prioritize streaming flows over elastic flows.
Let ΦCW be the set of all possible CWmin values that can be used by uplink elastic flows, with ΦCW =
{32, 64, 128, 256, 1024}. When the CAC receives a new request of a TCP uplink flow, it computes the
suitable CWmin value for the new and remaining active uplink elastic flows and broadcasts the new CWmin
value. If there are no VoIP flows in the system we assume that all nodes and the AP use the default value
of CWmin .
6.1.3
Uplink differentiation via different values of AIF S
Another possibility is to use different AIF S values to prioritize streaming flows over elastic flows. Let ΦAIF S
be the set of all possible AIF S values that can be used by uplink elastic flows, with ΦA = {4, 5, 6, 7, 8, 9}.
The AP : ACvoip queue always use Avoip = 4. When the CAC receives a new request of a TCP uplink flow,
it computes the suitable AIF S value for the new and remaining active uplink elastic flows and broadcasts
the new CWmin value. If there are no VoIP flows in the system we assume that all nodes and the AP use
the default value of AIF S equal to 4.
6.1.4
Uplink differentiation via different values of T XOP
In previous section (VoIP performance discussion) we have observed that the AP is the bottle-neck for VoIP
performance. In order to give priority to the AP, we propose to use different T XOPAP values that prioritize
AP streaming flows over other flows (only active in ACudp ). Let ΦT XOP be the set of all possible T XOP
14
values that can be used by AP : ACudp flows, with ΦT XOP = {4, 6, 8, 10, 12, 14}. When the CAC receives a
new request of a TCP uplink flow, it computes the suitable T XOP value for the ACudp queue of the AP.
6.1.5
Uplink differentiation via different values of AIF S, CWmin and T XOP (combined)
Finally, in this last configuration, we fix the A for elastic flows to a value equal to 7 (AP inclusive) and a
CWmin value equal to 32. For VoIP flows, the A value is fixed to 0 and the CWmin equal to 8. Moreover,
we propose to use different T XOPAP values that prioritize AP streaming flows over the other flows. Let
ΦT XOP be the set of all possible T XOP values that can be used by AP : ACudp flows, with ΦT XOP =
{4, 6, 8, 10, 12, 14}. When the CAC receives a new request of a TCP uplink flow, it computes the suitable
T XOP value for the ACudp queue of the AP.
6.2
Proposed algorithm
We propose an algorithm based on the a priori estimations provided by the model presented in previous
section to predict the network behavior when a new flow request is received. Each request is configured to
provide at least the following information: i) flow type (F), that can be elastic or streaming, ii) requested
bandwidth (B), and iii) average frame length (L). Using these parameters, the suggested algorithm operates
as follows,
1. A new request is characterized by the admission control with the vector (F, B, L).
2. Using the current system information and taking into account the new flow request, the new system
state is estimated, depending on:
• If the new request is for a downlink elastic flow, it is accepted if the number of downlink elastic
th
flows is lower than the threshold Ne,d
. The elastic downlink throughput is auto-regulated by the
dual-queue mechanism and the TCP dynamics.
• If the new request is for an uplink elastic flow, it is accepted if the number of uplink elastic flows
th
is lower than the threshold Ne,u
and if the new state is feasible. Otherwise, it tests from the set
of CWmin values whether the new state is possible.
• If the new request is for a downlink streaming flow, the CAC evaluates the queue utilization of the
∗
downlink UDP queue. If ρ∗s,d < ρth
s,d , the new flow is accepted. The ρs,d parameter is estimated
considering also the presence of the new flow. After accepting the new flow, the current ρs,d is
also updated with the information of the new flow.
• If the new request is for an uplink streaming flow, the CAC evaluates whether the new system
state is feasible. If not, it looks for another combination of MAC parameters to make the new
state feasible.
15
• If the new request is for a bidirectional streaming flow, the system evaluates if both uplink and
downlink flows can be accepted by using previous explanations.
3. If no state is feasible, reject the incoming flow.
6.3
6.3.1
Performance Evaluation
Source Traffic Models
The G.729 flow traffic model The VoIP calls use the G.729 codec with 8 Kbps bandwidth. Each flow is
modeled by a Poisson process with packet length equal to 20 Bytes with and packet sending rate of
βs = 50 packets/second. The RT P , U DP and IP header are added to the voice packet, resulting in a
packet length of L = 60 Bytes at the entrance of the MAC layer. Thus, a raw bandwidth of Bs = 24
Kbps has to be managed by the MAC layer for each VoIP flow.
A bidirectional TCP flow model for WLANs Modeling bidirectional TCP flows is complex due to the
interaction in the AP queue of the two types of packets: ACK and data packets. For further details
and a extended discussion about TCP performance in WLAN, see [12, 13, 19, 20]. We suggest a simple
approximation which captures the main tendencies observed:
• The downlink queue is always saturated. The average packet length transmitted by the AP is
computed from ELd = φd Ltcp + φu Lack where φd and φu are the probability that a packet sent
by the AP is a data or an ACK packet.
• These probabilities are computed from: φd = 1 − φu and φu = ne,u /(ne,u + ne,d ). Note that, if
ne,d = 0, this model is applicable in the uplink and if ne,u = 0, the model is applicable for the
downlink.
• Mobile nodes with uplink data packets are always saturated.
• Nodes with uplink ACKs have βack = λe,d /ne,d , where βe,d = φd /Xd (ELd ) is the downlink (AP)
packet rate 2 .
At the access point queue ACKs controlled by the transmission opportunities of mobile nodes compete
with data packets of downlink flows. As the number of uplink flows increases, since mobile nodes have
more transmission opportunities than the AP, the number of ACKs in the AP increases. Thus, the
downlink flows suffer for both contending for buffer space in the AP, and for contending on the access
to the channel.
The TCP packet length considered is equal to 1500 Bytes (including the TCP header).
2 To
simplify the model computation, in the results presented, we have assumed that ACK queues are also saturated.
16
voip
tcp
voip
tcp
We refer to Ss,d
(Ss,u
) to the downlink (uplink) VoIP traffic and Se,d
(Se,u
) to the downlink (uplink)
TCP traffic.
6.3.2
Model of a cell
Under the assumption of exponential distributions of flow arrivals and departures, the system can be described
by a Continuous Time Markov Chain (CTMC). If we also assume that all VoIP calls comprise one uplink and
one downlink flow and use the same codec, then the state of the CTMC is given by the vector (ne,d , ne,u , ns )
where ne,d , ne,u and ns denote the number of elastic flows (downlink and uplink) and VoIP calls that are active
in the cell. To solve this CTMC we suggest to break the three-dimensional CTMC in two bi-dimensional
CTMCs. First CTMC (CT M CA ) comprises the situation where the VoIP calls compete with uplink TCP
flows and second CTMC (CT M CB ) the situation where downlink TCP flows compete with uplink TCP
flows. The partial results of both CTMC can be averaged using the approximation that with probability ρs,d
the system works in the situation described by CT M CA and with probability 1 − ρs,d the system behavior
can be modeled by CT M CB .
While the number of elastic flows can grow to infinity, the maximum number of streaming flows is limited
th
by the bandwidth requirements of the voice calls to Nvoip
. In order to solve these infinite bi-dimensional
CTMCs, we need to truncate the state space. Without loss of generality, we introduce a realistic minimum
th
th
bandwidth Be,min required for an elastic flow which gives a maximum number of Ne,u
(Ne,d
) uplink (downlink)
elastic flows. The CTMCs state space is described by
voip
tcp
CT M CA : SA = {(ne,u , ns )| Se,u
(ne,u , ns )/ne,u ≥ Be,min , Ss,d
(ne,u , ns ) > 0.97 · ns Bs }
tcp
tcp
(ne,u , ne,d )/ne,u ≥ Be,min , Se,d
CT M CB : SB = {(ne,u , ne,d )| Se,u
(ne,u , ne,d )/ne,d ≥ Be,min }
(22)
For both voice and elastic flows the user population is considered to be infinite with steady state arrival
rates λe,u and λe,d for elastic flows and λs for VoIP calls. The elastic flow duration is function of the bandwidth
observed by the elastic flows and the flow length (amount of data to transmit) F Le , with departure rate equal
tcp
to µe,x = Se,x
(..)/(ne,x F Le ), and µs for streaming flows, which have a fixed average duration. A possible
example of both CTMC is depicted in Figure 4 when the tuned parameter is CWmin .
6.3.3
Parameters
The goal of this section is to evaluate the effect of elastic uplink flows over the capacity of VoIP calls. In Table
6 we show the parameters considered to test our CAC algorithm. In all cases, the flow arrival and departure
follow a Poisson process, the flow length has an exponential distribution and, for the sake of simplicity,
th
th
= 10 of active elastic flows in the system in all
Be,min is computed to allow a maximum number Ne,u
= Ne,d
17
CTMCB
CTMCA
--
--
--
32
32
32
32
32
downlink TCP flows
VoIP calls
--
--
--
--
--
--
--
--
--
--
--
--
32
32
32
64
128
32
32
32
32
32
32
64
64
128
256
32
32
32
32
32
32
32
128
256
256
512
32
32
32
32
32
32
32
512
1024 1024
32
32
32
32
32
a) Simple CAC
uplink TCP flows
uplink TCP flows
VoIP calls
a) Adaptive CAC
Figure 4: CTMCs Example. Feasible states and CWmin values for uplink TCP flows
λs (flows/second)
1/µs (seconds/flow)
λe,d (flows/second)
λe,u (flows/second)
F Le (Mbits)
Scenario 1
variable
240
0.5
0.5
1, 2
Scenario 2
0.0083
240
0.5
variable
1, 2
Scenario 3
0.0083
240
0.5
0.5
variable
Table 6: Parameters for CAC evaluation
situations.
6.4
Numerical Results
In this section we present some numerical results to investigate the performance of the proposed CAC scheme.
Results are shown as the comparison of the performance achieved by the WLAN using a non adaptive CAC
called simple CAC, according to which all flows always use fixed values of CWmin , AIF S and/or T XOP ,
and using the proposed CAC scheme, called adaptive CAC which tunes one or more parameters.
The results obtained using the adaptive CAC are better understood if we take into consideration: i) the
number of feasible states of the CTMC grows (i.e., the number of coexisting uplink TCP flows and VoIP calls
grows), ii) the adaptive CAC reduces the instantaneous throughput of TCP uplink flows, increasing their
latency (time they are active in the system) and iii) the adaptive CAC is not preemptive (it is not able to
block already existing flows, only reduce the rate of uplink TCP flows until the last Φ value is reached).
In order to avoid repetitive comments, we summarize the main aspects observed in results and left to the
reader a detailed comparison of them.
In Figures 5, 8, 11 and 14 we investigate the effect of increase the voice arrival rate in the blocking
probability of VoIP calls, uplink and downlink TCP flows and in their aggregated throughput. Notice that in
some cases (beyond λs = 0.015), the adaptive CAC show worst results than the simple CAC due the to the
18
intrinsic reduction in the blocking probability of uplink elastic flows. Obviously, better results are obtained
using the scheme which combines the use of CWmin , T XOP and AIF S.
In Figures 6, 9, 12 and 15 we left constant the arrival rate of VoIP calls to test the sensibility of the novel
scheme in front variations of the traffic intensity of TCP uplink flows. For both CAC schemes the blocking
probability of VoIP calls increases as the traffic intensity of TCP uplink flows also increases. However, under
the adaptive CAC the blocking probability exhibits substantially lower values, which tend to a constant one,
showing the desirable insensibility property. Note that the scheme which use the CWmin parameter obtain
a higher differentiation than the schemes which only use the T XOP and AIF S parameter.
Finally, in Figures 7, 10, 13 and 16 we evaluate the impact of the elastic flow length F Le . As expected,
as the elastic flow length increases the blocking probabilities of VoIP calls also increases, with lower values if
the system uses the adaptive CAC.
In all situations, the higher number of accepted VoIP calls using the adaptive CAC results in an increment
of the VoIP throughput and then, a higher utilization (ρs,d ) of the downlink ACudp queue at the AP, decreasing
the transmission opportunities of the TCP downlink traffic. This situation entails an increase of the blocking
probability of downlink TCP flows.
Is worth to note the minor impact of tuning the T XOP parameter in the combined scheme. We can
conclude that CWmin and AIF S are better suitable for traffic differentiation. Although, the T XOP is
useful in order to reduce the congestion of a node when it is overloaded by its own traffic but can achieve
enough channel access opportunities to avoid starvation.
7
Conclusions and Future Work
We have discussed some issues related to the provision of integrated services through WiFi access networks.
The popularity of WiFi access and the common use of a variety of different services is making this topic the
more and more crucial for operators in the field.
In particular, the performance of the IEEE 802.11e MAC protocol (EDCA) was investigated by means
of a novel user-centric model that was validated against simulation results. The model was used to analyze
the case of heterogeneous traffic scenarios, in which elastic and streaming traffic, representing respectively
TCP-based applications and streaming flows, share the common radio resources.
The analysis suggested that, in order to provide good quality of service to traffic flows whose requirements
are so different to each other, call admission control is needed. A novel scheme was then proposed based on
both the use of the network state and a smart setting of the MAC layer parameters.
The future work resides in how the optimum parameters can be used to achieve the best possible network performance. Several algorithms have to be developed in order to achieve dynamically this optimum
19
performance. Currently, some works address this problem but use heuristic algorithms (such as increase the
TXOP or decrease the CWmin [21, 22], similarly to the used in this report) without presenting clear results
about the influence over the system performance.
8
Acknowledgements
The work inside this report was partially supported by Catalonian Government under the i2CAT (Advanced
Internet in Catalonia) project, Spanish Government under project TIC2003-09279-C02-01, and by the European Commission under NEWCOM network of excellence.
20
1
1
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.9
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.7
0.6
0.5
0.4
0.3
0.2
Blocking Probability Downlink TCP flows
0.8
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.8
0.7
0.6
0.5
0.4
0.3
1
0.5
0.2
0.1
0
1.5
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.9
0.1
0
0.01
0.02
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(a)
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(b)
4
0.06
x 10
5
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
16
0.05
5
x 10
15
0.04
(c)
5
x 10
18
0.03
λs
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
4.5
12
10
8
6
Average TCP Throughput (Downlink)
14
Average TCP Throughput (Uplink)
Average Througput VoIP calls (Downlink)
4
10
5
3.5
3
2.5
2
1.5
4
1
2
0.5
0
0
0.01
0.02
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(d)
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(e)
0.03
λs
0.04
0.05
0.06
(f)
Figure 5: CWmin . (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
1.5
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
0.6
0.4
0.8
0.6
0.4
0
0.5
1
1.5
λe,u
2
2.5
3
0
3.5
0
0.5
1
(a)
0.5
1.5
λe,u
2
2.5
0
3
0
0.5
1
(b)
4
2
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
4.5
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
2
3
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
3.5
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
3
2.5
x 10
4
1.6
4
2
5
x 10
1.8
5
1.5
λe,u
(c)
6
x 10
6
Average Througput VoIP calls (Downlink)
1
0.2
0.2
7
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
Blocking Probability Downlink TCP flows
Blocking Probability VoIP calls
1
0.8
0
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
1
Blocking Probability Uplink TCP flows
1.2
1.4
1.2
1
0.8
0.6
3
2.5
2
1.5
1
0.4
1
0.5
0.2
0
0
0.5
1
1.5
λe,u
(d)
2
2.5
3
0
0
0.5
1
1.5
λe,u
(e)
2
2.5
3
0
0
0.5
1
1.5
λe,u
2
2.5
3
(f)
Figure 6: CWmin . (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
21
1
0.5
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
0.9
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.6
0.5
0.4
0.3
0.2
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.35
0.3
0.25
0.2
0.15
1
0.5
0.1
0.1
0.05
0
2
4
6
8
k
10
12
14
0
16
0
2
4
6
(a)
8
k
10
12
14
0
16
0
2
4
6
(b)
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
5
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
16
14
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
3
2
14
16
x 10
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
4
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
4
12
4.5
6
5
10
5
x 10
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
8
k
(c)
5
4
x 10
7
Average Througput VoIP calls (Downlink)
−
−
−
−
Blocking Probability Downlink TCP flows
0.7
8
b
b
b
b
0.4
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.8
0
1.5
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
0.45
12
10
8
6
3.5
3
2.5
2
1.5
4
1
1
0
2
0
2
4
6
8
k
10
12
14
0
16
0.5
0
2
4
6
(d)
8
k
10
12
14
0
16
0
2
4
6
(e)
8
k
10
12
14
16
(f)
Figure 7: CWmin . (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.4
0.3
0.2
0
0.015
λs
0.02
0.025
0.03
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
10
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
simple CAC
simple CAC
adaptive CAC
adaptive CAC
1
0.6
0.4
0
0.005
0.01
0.015
λe
0.02
0.025
0
0.03
0
0.005
0.01
(b)
x 10
−
−
−
−
0.8
0.015
λs
0.02
0.025
0.03
(c)
5
1.8
b
b
b
b
0.2
(a)
5
2
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.2
0
0.01
−
−
−
−
0.3
0.1
0.005
b
b
b
b
0.4
0.1
0
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.5
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
b
b
b
b
Blocking Probability Downlink TCP flows
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.5
5
x 10
4
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
9
x 10
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
3.5
1.4
1.2
1
0.8
0.6
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
Average Througput VoIP calls (Downlink)
1.6
8
7
6
5
3
2.5
2
1.5
0.4
4
1
3
0.5
0.2
0
0
0.005
0.01
0.015
λs
(d)
0.02
0.025
0.03
0
0.005
0.01
0.015
λs
(e)
0.02
0.025
0.03
0
0.005
0.01
0.015
λs
0.02
0.025
0.03
(f)
Figure 8: TXOP. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
22
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6 b − simple CAC
FLe=2E6 b − simple CAC
FL =1E6 b − adaptive CAC
e
FLe=2E6 b − adaptive CAC
1.2
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
Blocking Probability VoIP calls
0.8
0.6
0.4
0.8
0.6
0.4
0.2
0.2
0
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
1
1
0
0.5
1
1.5
λe,u
2
2.5
0
3
0.4
0
0.5
1
1.5
λe,u
2
2.5
0
3
0
0.5
1
(b)
4
2
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
2
2.5
3
5
x 10
4
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.8
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
x 10
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
3.5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
3.5
3
2.5
2
1.5
Average TCP Throughput (Downlink)
1.6
Average TCP Throughput (Uplink)
4
1.5
λe,u
(c)
6
x 10
4.5
Average Througput VoIP calls (Downlink)
0.6
0.2
(a)
5
1
0.8
1.4
1.2
1
0.8
0.6
3
2.5
2
1.5
1
1
0.4
0.5
0
0.5
0.2
0
0.5
1
1.5
λe,u
2
2.5
0
3
0
0.5
1
(d)
1.5
λe,u
2
2.5
0
3
0
0.5
1
(e)
1.5
λe,u
2
2.5
3
(f)
Figure 9: TXOP. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
0.4
0.25
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
0.35
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.2
0.15
Blocking Probability Downlink TCP flows
0.2
0.3
0.25
0.15
0.1
0.1
1
0.8
0.6
0.4
0.05
0.2
0.05
0
0
2
4
6
k
8
10
0
12
0
2
4
(a)
8
10
0
12
2
4
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
5
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
10
8
6
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
3.5
3
2.5
2
1.5
4
4
12
4
6
4.5
10
x 10
4.5
12
5
8
(c)
14
5.5
6
k
5
x 10
x 10
6.5
Average Througput VoIP calls (Downlink)
0
(b)
5
4
7
6
k
1
3.5
2
0.5
3
0
2
4
6
k
(d)
8
10
12
0
2
4
6
k
(e)
8
10
12
0
2
4
6
k
8
10
12
(f)
Figure 10: TXOP. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
23
1
0.8
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.9
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.7
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.7
0.6
0.5
0.4
0.3
0.6
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.8
0.5
0.4
0.3
0.2
1
0.8
0.6
0.4
0.2
0
0.2
0.1
0.1
0
0.01
0.02
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(a)
0.04
0.05
0
0.06
0
0.01
0.02
(b)
5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.04
0.05
0.06
5
x 10
12
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.8
0.03
λs
(c)
5
x 10
2
0.03
λs
6
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
10
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
x 10
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
1.4
1.2
1
0.8
0.6
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
Average Througput VoIP calls (Downlink)
1.6
8
6
4
4
3
2
0.4
2
1
0.2
0
0
0.01
0.02
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(d)
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(e)
0.03
λs
0.04
0.05
0.06
(f)
Figure 11: AIFS. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
1
1.5
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.9
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.7
0.6
0.5
0.4
0.3
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.8
0.8
0.6
0.4
1
0.5
0.2
0.2
0.1
0
0
0.5
1
1.5
λe,u
2
2.5
0
3
0
0.5
1
(a)
2
2.5
0
3
0
0.5
1
(b)
4
5
1.5
λe,u
x 10
2
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
2
2.5
3
(c)
6
4.5
1.5
λe,u
5
x 10
4
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
1.8
x 10
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
3.5
3.5
3
2.5
Average TCP Throughput (Downlink)
4
Average TCP Throughput (Uplink)
Average Througput VoIP calls (Downlink)
1.6
1.4
1.2
1
0.8
0.6
3
2.5
2
1.5
1
0.4
2
0.5
0.2
1.5
0
0.5
1
1.5
λe,u
(d)
2
2.5
3
0
0
0.5
1
1.5
λe,u
(e)
2
2.5
3
0
0
0.5
1
1.5
λe,u
2
2.5
3
(f)
Figure 12: AIFS. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
24
1.5
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
Blocking Probability VoIP calls
0.5
0.4
0.3
0.2
0
2
4
6
8
k
10
12
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
0.2
0.1
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
1
0.5
14
0
16
0
2
4
6
8
k
10
12
14
0
16
0
2
4
6
(b)
4
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
10
12
14
16
5
x 10
18
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
8
k
(c)
5
x 10
7
6
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
16
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
x 10
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
5
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
14
5
4
3
Average TCP Throughput (Downlink)
6
Average TCP Throughput (Uplink)
Average Througput VoIP calls (Downlink)
−
−
−
−
0.15
(a)
8
b
b
b
b
0.05
0.1
0
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
0.25
Blocking Probability Uplink TCP flows
b
b
b
b
Blocking Probability Downlink TCP flows
FL =1E5
e
FLe=2E5
FLe=1E5
FLe=2E5
0.6
12
10
8
6
4
3
2
2
4
1
1
0
2
0
2
4
6
8
k
10
12
14
0
16
0
2
4
6
(d)
8
k
10
12
14
0
16
0
2
4
6
(e)
8
k
10
12
14
16
(f)
Figure 13: AIFS. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for elastic uplink
flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink Throughput
VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average Downlink
Throughput elastic downlink flows,
1
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.9
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.6
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.7
0.6
0.5
0.4
0.3
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.8
0.5
0.4
0.3
0.2
1
0.8
0.6
0.4
0.2
0.1
0.2
0.1
0
0
0.01
0.02
0.03
λs
0.04
0.05
0
0.06
0
0.01
0.02
(a)
0.05
0
0.06
x 10
10
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
x 10
5
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
1.2
1
0.8
0.6
7
6
5
4
3
1
(d)
0
FL =1E6 b − simple CAC
e
FL =2E6 b − simple CAC
e
FLe=1E6 b − adaptive CAC
FLe=2E6 b − adaptive CAC
2
0.5
0.06
x 10
1.5
1
0.05
0.06
3
2
0.04
0.05
2.5
0.2
0.03
λs
0.04
3.5
0.4
0.02
0.03
λe
4
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
1.4
0.01
0.02
4.5
8
0
0.01
5
9
1.6
0
0
(c)
5
1.8
Average Througput VoIP calls (Downlink)
0.04
(b)
5
2
0.03
λs
0
0.01
0.02
0.03
λs
(e)
0.04
0.05
0.06
0
0
0.01
0.02
0.03
λs
0.04
0.05
0.06
(f)
Figure 14: Combined. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for
elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
25
0.02
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
0.018
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.014
0.012
0.01
0.008
0.006
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.016
1
0.8
0.6
0.4
1
0.8
0.6
0.4
0.004
0.2
0.2
0.002
0
0
0.5
1
1.5
λe,u
2
2.5
0
3
0
0.5
1
(a)
2.5
0
3
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
5
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
1.8
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
6
5
4
3
1.4
1.2
1
0.8
0.6
1
0
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
2
0.5
3
x 10
1.5
0.2
2.5
3
3
0.4
2
2.5
2.5
1
1.5
λe,u
2
3.5
2
1
1.5
λe,u
4
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
7
0.5
1
4.5
1.6
0
0.5
5
x 10
2
FLe=1E6
FLe=2E6
FLe=1E6
FLe=2E6
8
0
0
(c)
6
x 10
9
Average Througput VoIP calls (Downlink)
2
(b)
4
10
1.5
λe,u
0
0.5
1
(d)
1.5
λe,u
2
2.5
0
3
0
0.5
1
(e)
1.5
λe,u
2
2.5
3
(f)
Figure 15: Combined. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for
elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
0.02
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
0.018
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
FL =1E5 b − simple CAC
e
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
0
10
FLe=1E5
FLe=2E5
FLe=1E5
FLe=2E5
1.2
b
b
b
b
−
−
−
−
simple CAC
simple CAC
adaptive CAC
adaptive CAC
0.014
0.012
0.01
0.008
0.006
Blocking Probability Downlink TCP flows
Blocking Probability Uplink TCP flows
Blocking Probability VoIP calls
0.016
−1
10
−2
10
−3
10
1
0.8
0.6
0.4
0.004
0.2
0.002
−4
10
0
0
2
4
6
k
8
10
0
12
2
4
(a)
10
0
12
0
2
4
x 10
15
x 10
6
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
Average TCP Throughput (Downlink)
Average TCP Throughput (Uplink)
4.76
10
12
x 10
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
5
4.79
4.77
8
5
FLe=1E5 b − simple CAC
FLe=2E5 b − simple CAC
FLe=1E5 b − adaptive CAC
FLe=2E5 b − adaptive CAC
4.78
6
k
(c)
5
4.8
Average Througput VoIP calls (Downlink)
8
(b)
4
4.81
6
k
10
5
4
3
2
4.75
1
4.74
4.73
0
2
4
6
k
(d)
8
10
12
0
0
2
4
6
k
(e)
8
10
12
0
0
2
4
6
k
8
10
12
(f)
Figure 16: Combined. (a) BPs - Blocking probability VoIP calls, (b) BPe,u - Blocking probability for
elastic uplink flows, (c) BPe,d - Blocking probability for elastic downlink flows, (d) ESs - Average Downlink
Throughput VoIP calls, (e) ESe,u - Average Downlink Throughput elastic uplink flows, (f) ESe,d - Average
Downlink Throughput elastic downlink flows,
26
References
[1] IEEE Std 802.11. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. ANSI/IEEE Std 802.11, 1999 Edition (Revised 2003).
[2] Martin Heusse, Franck Rousseau, Gilles Berger-Sabbatel, and Andrzej Duda. Performance Anomaly of
802.11b. IEEE INFOCOM 2003, San Francisco, USA, April 2003.
[3] Deyun Gao, Jianfei Cai, and King Ngi Ngan. Admission control in IEEE 802.11e wireless LANs. IEEE
Network, vol. 19:4, p. 6- 13, 4, July-Aug. 2005.
[4] IEEE Std 802.11e. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; Amendment: Medium Access Control (MAC) Quality of Service Enhancements. IEEE Std
802.11e, 2005.
[5] Giuseppe Bianchi. Performance Analysis of the IEEE 802.11 Distributed Coordination Function. IEEE
Journal on Selected Areas in Communications, Vol. 18, No. 3, March 2000.
[6] Y.C. Tay and K.C. Chua. A Capacity Analysis for the IEEE 802.11 MAC Protocol. Wireless Networks
7, 159-171, March 2001.
[7] Haitao Wu, Yang Peng, Keping Long, Shiduan Cheng, and Jian Ma. Performance of Reliable Transport
Protocol over IEEE 802.11 Wireless LAN: Analysis and Enhancement. IEEE INFOCOM 2002, New
York, USA, June 2002.
[8] Paal E. Engelstad and Olav N. Østerbø. Non-Saturation and Saturation Analysis of IEEE 802.11e EDCF
with Starvation Prediction. In ACM/IEEE MSWIM 2005, Montreal, Quebec, Canada, November 2005.
[9] Gilbert (Gang) Chen. Component Oriented Simulation Toolkit. http://www.cs.rpi.edu/∼cheng3/, 2004.
[10] J. Barceló, A. Sfairoupoulou, J. Infante, M. Oliver, and C. Macián. Barcelona’s Open Access Network
Pilot. IEEE/Create-Net Conference on Testbeds and Research Infrastructures for the Development of
Networks and Communities (TrindentCom’06), Barcelona, Spain, July 2006.
[11] C. Casetti and C.-F. Chiasserini. Improving Fairness and Throughput for Voice Traffic in 802.11e EDCA.
IEEE PIMRC 2004, Barcelona, Spain, September 2004.
[12] Raffaele Bruno, Marco Conti, and Enrico Gregori. Analytical Modeling of TCP Clients in Wi-Fi Hot
Spot Networks. Networking 2004, LNCS 3042, pp. 626-637, May 2004.
[13] Saar Pilosof, Ramachandran Ramjee, Danny Raz, Yuval Shavitt, and Prasun Sinha. Understanding
TCP fairness over Wireless LAN. IEEE INFOCOM 2003, San Francisco, USA, March, April 2003.
27
[14] Jeonggyun Yu, Sunghyun Choi, and Jaehwan Lee. Enhancement of VoIP over IEEE 802.11 WLAN via
Dual Queue Strategy. IEEE International Conference on Communications (ICC’04), Paris, France,
June 2004.
[15] Chun-Ting Chou, Kang G. Shin., and Sai N. Shankar. Inter-frame space (IFS) based service differentiation for IEEE 802.11 wireless LANs. In IEEE 58th Vehicular Technology Conference, VTC 2003-Fall,
October 2003.
[16] Albert Banchs, Xavier Pérez-Costa, and Daji Qiao. Providing Throughput Guarantees in IEEE 802.11e
Wireless LANs. ITC Specialist Seminar on Providing QoS in Heterogeneous Environments, Berlin,
Germany, September 2003.
[17] A. Ksentini, A. Guéroui, and M. Naimi. Adaptive Transmission Opportunity with Admission Control
for IEEE 802.11e Networks. ACM/IEEE MSWIM 2005, Montreal, Quebec, Canada, October 2005.
[18] Ilenia Tinnirello and Sunghyun Choi. Efficiency Analysis of Burst Transmissions with Block ACK in
Contention-Based 802.11e WLANs. In Proc. IEEE ICC’2005, Seoul, Korea, May 2005.
[19] R. Bruno, M. Conti, and E. Gregori. Stochastic Models of TCP Flows over 802.11 WLANs. Technical
Report IIT TR-11/2005, CNR-IIT, June 2005.
[20] D.J. Leith and P.Clifford. Using the 802.11e EDCF to Achieve TCP Upload Fairness over WLAN links.
Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt’05), Trentino, Italy,
April 2005.
[21] Dennis Pong and Tim Moors. Call Admission Control for IEEE 802.11 Contention Acess Mechanism.
IEEE Globecom 2003, San Francisco, USA, December 2003.
[22] Liqiang Zhang and Sherali Zeadally. HARMONICA: Enhanced QoS Support with Admission Control for
IEEE 802.11 Contention-based Access. 10th IEEE Real-Time and Embedded Technology and Applications
Symposium (RTAS’04), Toronto, Canada, May 2004.
28