On the Use of Rate Configuration in the
Interoperation between DiffServ and 802.11e EDCA
A. Bai, T. Skeie, P. E. Engelstad, Member, IEEE
Abstract - This paper investigates rate configuration of the
Expedited Forwarding (EF) class of Differentiated Services
(DiffServ) when used with 802.11e EDCA. The rate
configuration problem is presented, and several approaches are
tested and evaluated in order to solve the problem. Results
reveal that the contention window makes rate configuration
very hard for the highest priority class (AC_VO) in 802.11e
EDCA. Our evaluations show that 802.11e EDCA is not able to
conform to DiffServ’s EF PHB specifications.
1
Keywords: IEEE 802.11e EDCA, DiffServ, PHB, Quality-ofService (QoS), Rate configuration, Drop.
I. INTRODUCTION
The demand for QoS provisioning is increasing in today’s
best effort Internet, and the Differentiated Services
(DiffServ) architecture [1] represents a promising candidate
technology for end-to-end QoS. Among the approaches that
exist, DiffServ is foreseen to become the de-facto standard
for providing IP QoS. This architecture is simple and more
scalable than per-flow QoS architectures, such as IntServ.
As wireless networks are being more and more widely
deployed, the demands for QoS in the wireless networks are
also increasing. The wireless access network will often be the
bottleneck on the path between the source and the receiver,
because of the nature of wireless communication. It is
therefore important to integrate the WLAN QoS architecture
with the end-to-end QoS concept adopted, for example
DiffServ, to support applications with QoS requirements on
wireless terminals.
The IEEE 802.11e standard was developed in order to
meet the QoS requirements in 802.11 WLANs [2]. The focus
in this paper is on the 802.11e EDCA, which gives
differentiation between four different priority classes – called
Access Categories (AC).
This paper addresses the interoperation of 802.11e EDCA
and the DiffServ architecture. It contributes with an
Manuscript received Feb 10, 2006. This work has been supported by the
OBAN project of the European Commissions 6th Framework Program. Other
OBAN partners are not committed under any circumstances by its content.
Alex Bai is a master student at University of Oslo and Telenor R&D,
Norway (email: aleksab@ifi.uio.no).
Tor Skeie is with Faculty of Informatics, University of Oslo, Norway
(email: tskeie@simula.no).
Paal E. Engelstad is with Telenor R&D, 1331 Fornebu, Norway (phone:
+47 41633776; fax: +47 67891812; e-mail: engelstad@ieee.org). He is also
associated with UniK / University of Oslo.
evaluation of rate configuration for the Expedited
Forwarding (EF) class. This evaluation is done both
analytically and by simulations.
Rate configuration (rate limiting) is a mechanism that
restricts the throughput for a class or priority, so the
throughput will never exceed a configured level. Rate
configuration is needed by admission control algorithms in
order to i.e. guarantee that one class will not harm
transmission of other classes, and is therefore an important
tool that must be well understood.
The next section gives an introduction to the previous
works in the field of interoperation between DiffServ and
IEEE 802.11e. It also presents the rate configuration
problem. Section 3 addresses this problem by an analytical
approach. Section 4 presents results obtained from the
simulations. An interesting property of the drop performance
of the highest class in 802.11e EDCA is identified and
discussed in Section 5. Finally the conclusions are drawn in
Section 6, and suggestions for future work are highlighted in
Section 7.
II. BACKGROUND
We have recently proposed a QoS architecture for
DiffServ in 802.11e [3]. In this architecture the whole
mapping between 802.11e's Access Categories and
DiffServ's Per-Hop Behaviors (PHBs) is located in a separate
and independent module. This module is called the “QoS
Mapping Module” (QMM), and it makes sure that a given
DiffServ PHB corresponds to a given 802.11e access
category. Since all mappings are placed inside the QMM,
neither signaling nor communication is needed between the
DiffServ node and the QoS-enabled Access Point (QAP). In
this way transparency is achieved.
The QMM is very simple in its functioning, because it
only performs table lookup, as well as reading and writing of
the MAC and IP headers in a packet. The QMM may be
placed inside the QAP, as depicted in Figure 1 (the figure
just illustrates the QMM concept and therefore the QAP is
not given in detail).
When a packet arrives from a DiffServ edge node, the
module intercepts the packet and gives it an 802.11e priority
that corresponds to the DiffServ's DSCP value. When a
packet comes from a QoS-enabled Station (QSTA), it is
given a DiffServ DSCP value. A typical example is the
mapping of the DiffServ Code Point (DSCP) for Best Effort
to 802.11e AC_BE.
http://folk.uio.no/paalee/
specification [4] will go to infinity, and the system will not
conform to the specification.
Setting the rate configuration of the EF traffic to a
reasonable level is a prerequisite for conformance with the
standard. Since this rate configuration setting is obviously
strongly dependent on the number of actively transmitting
stations, finding an appropriate rate control value can be a
difficult problem. This is what we refer to as the rate
configuration problem. In the following, we try to solve this
problem by an analytical approach.
III. ANALYTICAL APPROACH
Fig. 1. Proposed architecture.
The proposed mappings in [3] between DiffServ's PHBs
and 802.11e's traffic classes use only three out of the four
available ACs. The EF PHB is mapped to the highest priority
AC, AC_VO. The AF PHB is mapped to AC_VI and the BE
PHB is mapped to AC_BE. To be able to control the rate of
the EF traffic transmitted on the wireless channel, admission
control is needed for AC_VO. This rate control value is here
assumed statically set in the QAP.
For further information about the architecture, the QMM
module and how 802.11e's access categories conform to the
EF, AF and BE PHB requirements, refer to [3].
A. Rate configuration
Throughput - 16 stations scenario
2000
1800
parameters τ
Throughput [Kbps]
1600
1400
i
, Pi , Pb , P
s ,i
and Ps .
τi
is the
probability for a station in priority class i to transmit during a
generic slot time, Pi is the collision probability for the
1200
1000
800
priority class i, P
600
400
b
is the probability that the channel is
busy, P s , i is the probability of a successful transmission in
200
0
480
To conform to the EF PHB specification [4], queue
overflow for the EF class must be avoided. It would therefore
be beneficial if it was possible to make an algorithm or a
method for deciding the correct rate configuration value [3].
Then it would be possible to calculate the maximum rate
configuration value for a given set of stations that would
satisfy the latency demands for the EF class.
An obvious approach would be to analyze an analytical
model of 802.11e and extract an algorithm. Xiao has
presented an analytic model of 802.11e, which has proven to
be reliable when the system is in saturation [5]. Since rate
configuration only makes sense when the system is in
saturation, it is not necessary to use more advanced nonsaturation models, e.g. such as the model proposed by Paal
Engelstad and Olav Østerbø in [6].
Only the relevant equations from Xiao’s 802.11e
analytical model are given in this paper. A full overview of
Xiao’s analytic model can be found in [5]. Xiao’s model
encapsulates everything into five basic equations for the
2480
4480
6480
8480
10480
12480
Total offered load [Kbps]
EF
AF
BE
Fig. 2. Throughput for 16 stations.
For the scenarios with 12 and 16 stations the throughput
results of the simulations were not as expected [3]: The EF
class was rate configured (limited) to 5% of the channel rate,
but instead of staying at the configured throughput level, the
EF class converged to a value below this (Figure 2). The
configured rate for EF traffic was obviously set too high, and
because of the high number of stations, this lead to many
collisions on the channel. Therefore the actual throughput for
EF traffic became lower than the rate configuration level of
5% of channel rate (550Kbps). This is clearly not a desired
result since it will make the queue length for EF traffic grow
towards maximum, and latency demands for EF will not be
satisfied. Thus, the E_p parameter presented in the EF PHB
http://www.unik.no/personer/paalee
a slot time for priority i and P s is the probability for a
successful transmission in a slot time. By combining these
five equations, Xiao finds the maximum throughput for each
class as:
Si =
p s , iT E ( L )
(1 − p b ) ∂ + p s T s + [ p b − p s ]T c
where T
E ( L )
, ∂ ,T
s
and T
c
(1)
are constants.
A maximum rate configuration level can be found by
letting the number of stations in each priority class go to
infinity, and see if S i has an asymptotic value. If an
asymptote can be found, a maximum throughput level is also
found. It would then be possible to find a generic algorithm
for a given set of nodes. In order to find the limits of S i
when the number of stations goes to infinitive, a closer look
at the behavior of the parameters τ i , P i , Pb , P s , i and P s
In search of a rate configuration method, numerous
simulations where conducted. The ns-2 discrete event
simulator (version 2.26) was used for the evaluations,
together with an 802.11e EDCA extension model
implemented by the TKN group at the Technical University
of Berlin [7][8]. The configurations that were used for the
simulations are listed in Table 1
is needed.
A. The limits of P s , i
P s , i is given by
Ps ,i = niτ i (1 − τ i )
N −1
∏ (1 − τ
ni −1
h
) nh
(2)
h =0,h ≠ i
where n is the number of stations. The valid domains for
τi
and
τh
are
0 ≤ τ i ≤ 1, 0 ≤ τ h ≤ 1 .
For
simplicity, the analysis can be broken into two cases. The
first case is for τ i ∈ 0 ,1 ,τ h ∈ 0 ,1 , and the other case
[ ]
[ ]
is for 0 < τ i < 1,0 < τ h < 1 .
It is easy to see from Eq. (2) that the
term τ i ( 1 − τ i ) will be zero when τ i ∈ [0 ,1 ] . The
N −1
∏
(1 − τ h ) n h term will be zero when τ h = 1 , and
h = 0 ,h ≠ i
when τ h
= 0.
Hence,
when τ i ∈ [0 ,1 ], τ h ∈ [0 ,1 ] .
Ps,i
will
be
zero
For the remaining case ( 0 < τ i < 1,0 < τ h < 1 ) , we
observe that the terms (1 − τ i ) n i − 1 and
also go to zero when n → ∞ , since:
lim ln(1 − τ )n = lim n ln(1 − τ ) = −∞
n−>∞
n−>∞
IV. SIMULATION APPROACH
(1 − τ h ) nh will
(3)
Parameter
Channel Rate
Packet size
Traffic generator
Link delay
Stabilize time
Simulation duration
Queue length
Physical layer settings
EDCA parameters [AIFS,
CWmin, Cwmax, TXOP limit]
Table 1. Detailed configuration for the scenarios
The goal of the simulations was to find the correct rate
configuration value for the EF class in the 16 nodes scenario.
The motivation behind this was to compare the results found
by simulation with numerical analysis. If numerical and
simulation results correlate, further numerical results can be
extracted and extended to a rate configuration formula.
While performing the simulations, an interesting property
was revealed. It was not possible to set a rate configuration
level that would guarantee that the delay bounds would be
fulfilled. In other words, it was not possible to find a rate
configuration level that the EF class could maintain.
Drop percentage - 16 stations scenario
25
It can be shown that the divider of S i will go towards 1
n → ∞ by looking at the limits for
when
τ i , P i , P b , P s . These proofs have been left out
because of limited space, but the reader is encouraged to
confirm the results. Therefore the limits of S i is
lim S i = 0 .
n −>∞
This is not a desired result because the motivation behind
this analysis was to find a non-zero asymptote for S i , and
thus be able to find a rate configuration method for the EF
class. Another approach is needed if a rate configuration
method is to be found.
Drop percentage [%]
n→∞.
Si
AF (AC_1) = [2, 7, 15, 3]
BE (AC_3) = [7, 15, 1023, 0]
(3, 5, 8, 12, 16)
Number of stations
Hence, in any of the possible cases, Ps ,i → 0 when
B. The limits of
Value
11 Mbps
500 bytes (fixed)
All nodes sending CBR traffic
1us
50s
180s
5 packets
802.11b
EF (AC_0) = [2, 3, 7, 1.5]
20
15
10
5
0
30
120
210 300
390
480 570
660 750
840 930 1020 1110 1200 1290 1380
Total offered throughput [Kbps]
EF
AF
Fig. 3. Drop percentage for the EF class (in a 16 node scenario).
Figure 3 shows the drop percentage for the EF class for
the scenario given in section 2.1. The EF class was rate
configured to 5% of the channel rate (i.e. to 550 kb/s) while
the AF class was not rate configured at all. As shown with
both throughput and drop percentage results (Figure 2 and 3),
the EF class was not able stay at the configured level.
We also ran other simulations where the EF class was rate
configured to 3%, 1%, 0,5% and even 0,03%. Those
p=e
1
ln 0, 24
7
= 0,82
(4)
The division by seven in Eq. (4) reflects the recommended
number of retries of 802.11e EDCA (which our simulations
also used).
A collision probability of 82% is not unthinkable when
there are 16 stations and the channel is in saturation. Thus it
really should not come as a surprise that it is not possible to
rate configure the EF class when the number of stations is
high.
Several other simulations were performed with different
EDCA parameters. These results are omitted because of
limited space. The simulations were still not able to perform
Another interesting feature also emerged during the
simulations. If rate configuration was applied to all the three
classes (EF, AF and BE) during the simulation, the drop
percentage would stabilize. Both the AF class and the BE
class had to be rate configured along with the EF class in
order to achieve this result. If just one of the three classes
was rate configured too high or not at all, the drop percentage
would rise and the queue delay would also continue to rise.
Drop percentage - all classes rate configured
5
4,5
4
3,5
3
2,5
2
1,5
1
0,5
99
0
11
25
12
60
13
95
15
30
16
65
18
00
19
35
20
70
85
5
72
0
58
5
45
0
31
5
0
45
The reason for this unexpected behavior of the rate
configuration is the EDCA parameters. All the simulations
were performed with recommended EDCA parameters.
However, the contention window for the highest priority
class in 802.11e is initially very small [2]. An understanding
of what kind of data the highest priority class is supposed to
carry is needed in order to understand why the EDCA
parameters are set the way they are.
When IEEE standardized 802.11e, the purpose of the
highest priority class (priority 0) was different from
DiffServ’s highest priority class (EF). The EF class is not
intended for any specific data type, but is just meant to
deliver the data as fast and reliable as possible (and better
than all lower priority classes). The voice class (priority 0) in
802.11e is, however, intended for voice traffic. This is the
fundamental difference between the two standards and the
reason why rate configuration is so difficult.
The recommended EDCA parameters for the highest class
in 802.11e is set to achieve fast access to the medium at all
costs, even on behalf of some packet loss. This is why the
contention window is so small, since the intended data for the
class is voice traffic. It is less crucial if a voice packet is
discarded than a video packet (which has lower priority and a
higher contention window).
The impacts of a small contention window are obvious in
our simulations results. Because of the high number of
stations and many packet collisions, the drop percentage for
the highest 802.11e class rises very high. A drop percentage
of 24% (maximum drop percentage in Figure 3) for the
highest priority in 802.11e would indicate a collision
probability of 82%:
A. Drop percentage stabilizes
18
0
V. DROP PERCENTAGE
at the rate configuration level, although in some scenarios it
was possible to find a better match. Whether it is possible to
find an EDCA setting that makes it possible to rate configure
the EF class is left open. A more detailed study is needed to
confirm or discard this option.
Drop percentage [%]
simulations showed the same result as in Figure 3. The EF
class could not maintain the throughput level and dropped
below the configured rate level. This is a very interesting
property of 802.11e EDCA that has not been documented
before to our best knowledge.
This result has a large impact on admission control
algorithms, since it will be difficult to rate limit the highest
priority class in 802.11e as expected. This means that
admission control will be very hard to perform.
Total offered load [Kbps]
EF
AF
BE
Fig. 4. Drop percentage stabilizes.
As shown in Figure 4, the drop percentages for the EF and
AF classes stabilized and the throughput therefore also
stabilized. In this simulation, the EF class was rate
configured to 5%, AF to 1% and BE to 1% of the channel
rate. This is exactly the same scenario that is listed in section
2.1, except that the AF and BE class were also rate
configured.
The drop percentages stabilize in this scenario because the
channel is not in saturation. This might be an approach for an
admission control that needs rate configuration. By rate
configuring all the 802.11e classes and taking the drop
percentage into account, a maximum throughput limit can be
obtained.
Figure 5 shows a scenario where this approach could
have been used. It is the same scenario as shown in Figure 4,
where the highest priority class was rate configured to 5%,
the AF class to 1% and BE class to 1%. In Figure 5 it is
observed that the throughput stabilizes for the EF class.
Throughput - All classes rate configured
600
Throughput [Kbps]
500
400
300
200
100
5
0
5
0
0
20
7
19
3
18
0
16
6
15
3
13
9
5
0
5
12
6
99
0
11
2
85
5
58
5
72
0
45
0
31
5
45
18
0
0
Total offered load [Kpbs]
EF
AF
A simple and effective solution to the rate configuration
problem is to rate configure all three classes simultaneously.
This is because the number of collisions is brought under
control, and the drop percentages are stabilized. However,
since the drop probability for the EF class is still higher than
the AF and BE class, 802.11e is still not able to fulfill the EF
PHB specification [4].
In summary, our evaluations show that the 802.11e EDCA
is not able to conform to DiffServ’s EF PHB specifications,
because of the rate configuration problem regarding the drop
mechanism for the highest priority class in 802.11e EDCA.
BE
VII. FUTURE WORK
Fig. 5. Throughput for a scenario where all the classes are rate
configured.
As both Figure 4 and 5 shows, better results are achieved
when rate configuring is applied to all classes. Comparing
the EF class throughput in Figure 5 with that in Figure 2
shows radical improvements; the EF class achieves a stabile
throughput and it gets 100 Kb/s more throughput when the
AF and BE class is also rate configured.
The EF class is, however, still not able to stay at the
configured rate level because of the drop percentage. As
explained in section 5, this is because of how the contention
window works.
VI. CONCLUSION
This paper has gone deeper into the evaluation of how the
IEEE 802.11e standard for WLAN QoS is able to
interoperate with DiffServ. A brief overview of the
architecture along with its mapping was given, before the
rate configuration problem was explained in more detail.
An analytical study of the throughput for IEEE 802.11e
was given. The analysis concluded that the throughput goes
towards zero when the number of stations goes toward
infinity. This was perhaps not an unexpected result, but even
so it is important to investigate the properties of the
throughput and establish the result. The goal behind finding
an asymptote for the throughput was to find a rate
configuration level for the EF class. Since this turned out
negative, more simulations were performed in order to find a
rate configuration level by simulations.
It turned out to be impossible to rate configure the EF
class in 802.11e, regardless of how low or how high the rate
configuration was. Because of the EDCA parameters, many
collisions will occur because of a small contention window
and therefore the drop percentage could not be eliminated no
matter how the EF class was configured.
This problem has never been documented before, and is a
very serious problem when considering admission control for
802.11e EDCA. Being able to rate limit a class is usually an
absolute demand in admission control algorithms, and
solutions to work around the rate configuration problem
should therefore be investigated.
More study on how to set the EDCA parameters when rate
configuring the EF class is needed. It may be possible to
achieve close to zero drop probability for the EF class if the
EDCA parameters are set differently. This must, however,
not destroy the transmission of the other classes.
A more comprehensive study of the drop problem for the
highest class of 802.11e EDCA is needed. There might exist
solutions to the rate configuration problem, or solutions that
will efficiently eliminate the problem.
VIII. REFERENCES
[1] S. Blake, D. Black, M. Carlson, E. Davies , Z. Wang, W. Weiss, 'An
Architecture for Differentiated Services', IETF RFC 2475, December 1998.
[2] Wireless Medium Access Control (MAC) and Physical Layer (PHY)
specifications: Medium Access Control (MAC) Quality of Service
enhancements, IEEE draft standard P802.11e/D8.0, February 2004.
[3] Aleksander Bai, Paal Engelstad, Bjørn Selvig, Tor Skeie,
’Interoperation between DiffServ and 802.11e EDCA’, Norwegian Network
Research Seminar, 2005. (See also: http://www.unik.no/personer/paalee .)
[4] B. Davie, A. Charny, J.C.R. Bennett , K. Benson, J.Y. Le Boudec, W.
Courtney, S. Davari, V. Firoiu, D. Stiliadis, 'An Expedited Forwarding PHB
(Per-Hop Behavior)', IETF RFC 3246, March 2002.
[5] Yang Xiao, ‘Performance Analysis of IEEE 802.11e EDCF under
Saturation Condition’, IEEE Communications Society, 2004.
[6] Paal Engelstad, Olav Østerbø, ‘Non-Saturation and Saturation
Analysis of IEEE 802.11e EDCA with Starvation Prediction’, ACM,
Analysis and Simulation of Wireless and Mobile Systems, 2005. (See also:
http://folk.uio.no/paalee .)
[7] Sven Wietholter, Christian Hoene, 'Design and Verification of an
IEEE 802.11e EDCF Simulation Model in ns-2.26', Technical University
Berlin, Telecommunications Networks Group, Berlin November 2003.
[8] Kevin
Fall,
Kannan
Varadhan,
http://www.isi.edu/nsnam/ns/doc/index.html.
'The
ns
Manual',