Differentiated Services in 802.11e WLANs
Bjørn Selvig
Simula Reseach
Laboratory
bjornese@ifi.uio.no
Aleksander Bai
Telenor R&D / Univ.
of Oslo
aleksab@ifi.uio.no
Abstract
This paper focuses on how the IEEE 802.11e
standard for Quality of Service (QoS) in Wireless
Local Area networks (WLANs) can interoperate with
the Differentiated Services (DiffServ) architecture for
end-to-end IP QoS. It explores to which extent the
802.11e Enhanced Distributed Coordinated Access
(EDCA) can meet the requirements from the DiffServ
Per Hop Behavior (PHB) specifications. An
architecture for the use of DiffServ in an 802.11e
WLAN environment is first outlined. Then, a mapping
scheme from the PHBs to the 802.11e priority classes
is suggested. How well 802.11e EDCA conforms to the
DiffServ PHBs are finally evaluated by means of
simulations.
Keywords: IEEE 802.11e, DiffServ, PHB, Quality-ofService (QoS)
1. Introduction
The Internet of today provides no Quality of
Service (QoS) beyond the best effort treatment of
traffic. No guarantees are given regarding throughput,
delay, jitter, loss etc, even if there are applications with
such demands. A video-conference, for example,
requires relative stable throughput, delay and jitter. As
the use of QoS demanding applications like streaming
media increase, the need for QoS provisioning is
increasing.
The Differentiated Services (DiffServ) architecture
[1] represents a promising candidate technology for
end-to-end QoS on the Internet. Among the
approaches that exist (including IntServ), DiffServ is
foreseen to become the de-facto standard for providing
IP QoS. This architecture is simple and scalable
compared to other architectures for end-to-end QoS.
As wireless networks are being more and more
widely deployed, the demands for QoS in the wireless
Tor Skeie
Fac. of Informatics,
Univ. of Oslo
tskeie@simula.no
Paal Engelstad
Telenor R&D / Univ.
at Kjeller (UniK)
paalee@unik.no
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 with the end-toend QoS mechanisms used, 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).
In this paper we address the interoperation of
802.11e EDCA and the DiffServ architecture. An
evaluation of how well 802.11e EDCA conforms to the
DiffServ specifications is presented, and a mapping
between DiffServ and 802.11e is proposed.
Davik and Gjessing [3] did a similar analysis for the
interoperation of DiffServ and Resilient Packet Rings.
Here we undertake an analysis after the same lines as
in [3].
The next section gives the reader an introduction to
the various technologies, and present similarities and
differences between DiffServ and 802.11e. The reader
is pointed to related work concerning the
interoperation between DiffServ and 802.11e. An
architecture for the use of DiffServ in conjunction with
802.11e is presented in Section 3, and a mapping
scheme is suggested. Section 4 presents the simulation
scenario, and the results obtained from the simulations.
Finally the conclusions are drawn in Section 5, and
suggestions for future work are highlighted in Section
6.
2. Background
2.1. Differentiated Services (DiffServ)
http://folk.uio.no/paalee/
The DiffServ architecture is a framework for
providing end-to-end QoS in IP networks [1]. DiffServ
will provide prioritized differentiation between traffic
classes in the network, to better meet the different QoS
demands from different types of applications.
The DiffServ architecture consists of DiffServ
domains that are divided into edge and core nodes. The
most complex part of the DiffServ functionality is
implemented in the edge nodes, while the core nodes
are kept as simple as possible. A traffic classifier that
will classify the traffic into one of the specified PHBs
is placed inside the edge nodes, along with a traffic
conditioner that will mark the packet, measure the
traffic rate for each PHB aggregate, and shape the
traffic according to a given policy. Based on the packet
marking, the core nodes will classify the packet into a
PHB. Different traffic aggregates will then experience
different forwarding treatment by the core nodes in the
path depending on which PHB they belongs to,
identified by the differentiated services code point
(DSCP) in the packet header.
IETF has defined some standard PHBs that need to
be implemented by the DiffServ compatible nodes in
the network. The Expedited Forwarding (EF) PHB is
meant to give bandwidth, low latency and jitter
guarantees to its traffic [4]. This is achieved by giving
EF traffic strict priority over all other traffic, and to
rate control the amount of EF traffic in order to avoid
congestion. A node that is EF compliant must satisfy
given quantified delay and jitter values [4]. These
values are functions of the rate R for which the node
can support EF traffic. The equations for delay and
jitter that the node must be able to meet are [4]:
d_j <= f_j + e_p for all j > 0
(1)
Where f_j is defined iteratively by
f_0 = 0, d_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R,
for all j > 0
(2)
These equations set a bound on the jitter and delay
of each individual packet, and quantify the difference
between the ideal and the actual departure time for a
packet leaving a DiffServ node. The evaluation of EF
conformance in section 4.2 is based on these equations.
d_j is the actual departure time, while a_j is the arrival
time. f_j is the ideal time when a packet should leave
the node and e_p is an error term which expresses the
worst case difference between actual departure time
and ideal departure time for an individual packet. f_j is
computed by taking into account the arrival time for
this packet and the ideal and actual departure time for
the previous packet sent out from this node. l_j is the
http://www.unik.no/personer/paalee
packet size in bytes specified at the IP layer. The
expression l_j/R gives the transmission delay
introduced for the specific packet size used.
An EF compliant node must conform to these
equations, and be able to be characterized by the
possible rate values R and the worst-case error terms
e_p.
The Assured Forwarding (AF) PHBs, on the other
hand, represent a PHB group that is divided into one to
four different classes [5]. Each of the classes must
have a minimum of two and a maximum of four
different drop precedence values. In order to conform
to the AF PHB, every AF class must be assigned its
own amount of resources by the DiffServ compliant
nodes, and the packets within each micro-flow can not
be reordered.
In addition, there is the default PHB, which is
regular best effort forwarding. The best-effort traffic
will always have the lowest priority in a DiffServ
compliant node.
2.2. 802.11e
IEEE 802.11e is a standard for QoS improvements
of the 802.11 MAC layer, approved by IEEE in July
2005 [2]. 802.11e basically adds priorities to the MAC
layer, and provides improvements of the MAC access
mechanisms known from the legacy 802.11 WLAN.
The 802.11e implements a Hybrid Coordination
Function (HCF) with two different medium access
mechanisms; Enhanced Distributed Channel Access
(EDCA) and HCF Controlled Channel Access
(HCCA). The time on the channel is divided into super
frames, which consist of periods split by the two
medium access mechanisms. Those periods are called
the Contention Period (CP) and the Contention Free
Period (CFP), respectively. In the CFP the HCCA
medium access mechanism is used, and the QoS
enabled stations (QSTAs) are polled periodically by
the QAP
Figure 1 shows a typical 802.11e structure. Here we
have a QAP (QoS enabled Access Point) which is
typically connected to other infrastructure like the
Internet. 802.11e nodes, or the QoS enabled stations,
are connected to the QAP. This network structure is
called QBSS (QoS enabled Basic Service Set) in
802.11e and BSS in 802.11.
Figure 1. 802.11e QBSS.
When the QAP is in a CP, the EDCA medium
access mechanism is used. EDCA introduces four
Access Categories (AC) in each QSTAs. Eight user
priorities, called “traffic classes”, are mapped down to
these four ACs. This mapping is defined by the IEEE
802.11e standard [2]. Each of the ACs has its own
output queue for transmission on the channel, but
before a frame is put into one of these queues a
mapping from a traffic class to an AC takes place in
the 802.11e node.
The four ACs are called the AC Voice (AC_VO),
AC Video (AC_VI), AC Background (AC_BK) and
the AC Best effort (AC_BE). AC_VO has the highest
priority and is meant for voice traffic with strict
latency, jitter and bandwidth requirements. AC_VI is
meant for video traffic that has strict bandwidth
demands, but some looser latency and jitter demands
than voice does. AC_BK is meant for background
traffic and AC_BE for best effort traffic.
Admission control determines who are entitled to
network resources, and is therefore an important aspect
when offering QoS services. It is not mandatory to
implement admission control in an 802.11e network.
The QAP in an 802.11e network is the entity that
enforces and administers the optional admission
control, and will announce to surrounding stations
whether admission control is mandatory for each AC
or not. The actual admission control implementation is
vendor specific.
2.3. Related Work
Only few contributions have been published
regarding the required interoperation between DiffServ
and 802.11e, and very little work has been done to
evaluate how 802.11e conforms to the DiffServ's PHB.
Skyrianoglou et. al. [6] have proposed an adaptation
layer architecture, called Wireless Adaption Layer
(WAL ), between the link layer and the IP layer. This
WAL offers an interface to the higher and lower layer
that is independent of the technology used. The WAL
layer can implement the DiffServ functionality in the
nodes. Skyrianoglou et. al. also suggest a mapping
scheme between DiffServ's PHB and the service types.
Seyong Park et. al. [7] have investigated how the
DiffServ PHBs can be translated to 802.11e priority
classes. The proposed architecture uses 802.1D/Q
(bridge specification) priorities in the Ethernet between
the QAP and the DiffServ compatible access router.
Two different mapping schemes are suggested; 'Direct
mapped QoS between DSCP and TCID' and
hierarchical QoS architecture. TCID is the 802.11e
user priority value. Basically the hierarchical mapping
scheme requires DiffServ traffic conditioning
functionality at the network layer in the QSTAs in
addition to the 802.11e’s treatment of the traffic. The
direct mapped architecture, on the contrary, only needs
a module that performs packet classifying, marking,
and mapping between DiffServ's PHBs and 802.11e's
ACs in the QSTA network layer and relies to a larger
extent entirely on 802.11e’s medium access
mechanisms.
Both Park and Skyrianoglou have some practical
disadvantages though. The architecture of Park et. al.
[7] requires that the QSTAs are DiffServ aware. This is
because the QSTAs must be able to read the DSCP in
order to find the correct TCID value, and because the
QSTAs must implement a packet classifier and
conditioner [7]. Hence all the QSTAs must implement
new functionality in form of DiffServ awareness. This
is not a trivial task since it requires modification of all
the QSTAs and the QAP.
Skyrianoglou et. al. [6] use a transparent layer, so
the QSTA does not need to implement any new
functionality, but the WAL module must be added to
each QSTAs. This may be an easier task than what
Park et. al. propose, but still requires modification in
the QSTAs. The architecture of Skyrianoglou et. al.
assumes that the QAP is a router since WAL must be
placed below the IP layer and above the WLAN link
layer, which is a bold assumption after our opinion and
puts restrictions on the QAP. Also, Skyrianoglou et. al.
do not focus on 802.11e, so no evaluation regarding
802.11e is done.
The next section proposes a simple framework for
the interoperation between DiffServ and 802.11e that
improves the disadvantages discussed here.
3. Architecture
There are several different ways of making
DiffServ and 802.11e interoperate. Most approaches in
the literature add enhancements to the DiffServ
modules or modify the 802.11 MAC layer, so
interoperation can be achieved. Attempts to modify the
existing structure require extra functionality to be
implemented and increase complexity considerably.
In this paper, on the contrary, transparency between
DiffServ and 802.11e is assumed. This leads to a
simple architecture that is easy to implement.
3.1 Suggested architecture
We propose to realize a QoS architecture for
DiffServ and 802.11e by placing all the mapping
between 802.11e's access categories and DiffServ's
PHBs in a separate and independent module. We refer
to this module as the “QoS Mapping Module” (QMM).
The QMM will make sure that a given DiffServ PHB
corresponds to a given 802.11e access category. Since
all the mapping is placed inside the QMM, no
signaling or communicating between the DiffServ
node and the QAP is needed. Transparency is therefore
achieved throughout the architecture.
The QMM is very simple in its functioning, because
it only does 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 Figure 2
illustrates. The figure is just illustrating the QMM and
therefore the QAP is very simplified.
The QMM is added as a module in the QAP, and
therefore no assumption about the QAP is made like
Skyrianoglou et. al. do [6]. The QMM needs to
read/write the IP header in the packets for reading and
writing DSCP.
Putting the module inside the QAP is just one of
three possible configurations. The module could easily
also be placed inside the DiffServ edge node or a
regular node. These nodes may be connected with for
example 802.3 Ethernet, and in this case the nodes
need to implement for example the IEEE 802.1D MAC
bridge specification [8]. IEEE 802.1D adds priorities
to the MAC layer that corresponds to the eight user
priorities of 802.11e EDCA. If the module is not
placed inside a QAP, the node must implement 802.1D
to make the mapping from Ethernet to 802.11e.
When a packet arrives from a DiffServ edge node,
the module will intercept the packet and give it a
802.11e priority that corresponds to the DiffServ's
DSCP value. When a packet comes from a 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.
Figure 2. Proposed architecture.
This architecture requires implementation of the
QMM, while modification of neither the DiffServ edge
node nor the WLAN MAC layer is needed. The
module also only needs to be added to the QAP and no
modification of the QSTAs is needed like Park et. al
[7] and Skyrianoglou et. al. [6] assumes. Hence a
simple architecture is achieved.
This architecture could use both static and dynamic
mapping. If dynamic mapping should be implemented,
a more sophisticated form of admission control is
needed, because the module must be updated with the
latest mappings between 802.11e's priorities and the
DiffServ's PHBs. Thus an optional bandwidth broker
and the QAP must be able to communicate with the
module for dynamic mappings [9]. The QMM does not
specify the actual mapping, since the mapping could be
done either dynamically or statically. It is up to each
implementation of the architecture to define the
mapping.
3.1. Mapping
In addition to proposing the QMM as the key
building-block of the architecture, this paper also
suggests how the actual mapping can take place in the
module.
The proposed mapping between DiffServ's PHB
and 802.11e's traffic classes uses only three out of the
four available AC's in the QSTAs. 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 rate control the offered EF
traffic to the channel, admission control is needed for
AC_VO. Here the actual setting of this rate value is
assumed statically set in the QAP.
Upstream traffic is classified in the respective
QSTA into one of the station's ACs. This classification
is based on the QoS demands for the traffic, and this is
assumed to be a local decision in the QSTA. If the
chosen AC is AC_VO, the admission control unit
restricts the traffic.
The next section will evaluate how well the
802.11e's access categories conform to the EF, AF and
BE PHB requirements.
4. Evaluation by Simulations
The objective of this section is to evaluate to what
extent the 802.11e access classes conform to the
specifications for the DiffServ EF, AF and BE PHBs.
Throughput is evaluated for all three PHBs. The delay
and jitter are only evaluated for the EF PHB, because it
is only this PHB that has such requirements specified
[4].
The ns-2 discrete event simulator (version 2.26) is
used for the evaluations, together with an 802.11e
EDCA extension model implemented by the TKN
group at the Technical University of Berlin [10][11].
Throughput is measured per PHB traffic aggregate
at the QAP with linearly increasing offered load sent
from the QSTAs. The total offered load at each node is
shared between EF, AF and BE with 20%, 30% and
50% respectively. When the offered load for EF traffic
reaches a level of 5 % of the maximum channel rate,
which for the 802.11b physical layer is 11Mbps [12],
this traffic is rate limited. Delay and jitter are measured
for the EF traffic aggregate. Because the EDCA MAC
layer function basically implements a scheduling
system between the four different ACs, it is important
to find out how well this scheduling system
differentiates between the aggregate classes.
The simulation model used for the evaluations
measures average, maximum and minimum latency
between the time when a packet is sent from a QSTA
till it is received at the QAP. Total latency to transmit a
packet would include the Short Inter-Frame Space
(SIFS) time and time to send the acknowledge (ACK)
packet. The SIFS time is the time that the QSTA will
wait between the reception of a data packet and the
transmission of the following ACK packet. These are
not included in the presented results, but can be added
if desired. The equations that specify the conformance
requirements for the EF PHB are given in Eq. (1) and
Eq. (2) above. These equations compute the worst-case
time deviation between the actual departure times and
ideal departure times of two packets. The ideal
deviation between the departure times of two packets
is given by the ratio l_j/R, where l_j is packet length in
Bytes at the IP layer and R is the configured EF rate
for the node. The worst-case time deviation between
two packets is measured like this; the first packet is
assumed to experience the minimum possible latency
for a packet being sent from the QSTA and received by
the QAP. Furthermore, we assume that the next packet
experiences the maximum possible latency. The E_p
value from Eq. (1), which gives the worst-case
deviation between ideal and actual departure time is
then calculated using Eq. (3):
E_p = Maximum Latency – Minimum latency (3)
This equation gives a good estimate for the E_p
value for the 802.11e WLAN, since it gives the worst
possible deviation time between two packets. In the
next section the simulated scenario and the obtained
throughput and latency results will be presented.
4.1. Scenario
The scenario explored uses a simple topology with
a single QoS enabled access point (QAP) and a
varying number of QoS enabled stations (QSTAs) to
illustrate a standard WLAN area with 802.11e nodes.
The purpose of this scenario is to make the settings as
standard and simple as possible, so the evaluation will
be more manageable. By the same reason, the default
parameter settings (of medium access parameters such
as the minimum and maximum contention windows,
transmission opportunity lengths etc.) recommended
by the 802.11e specification is used [2].
We have five different sets of actively transmitting
nodes (3, 5, 8, 12, 16) which reflect five various
WLAN setups. All the nodes can hear both each other
and the access point. In the first configuration with
three nodes, we aim to simulate maybe the most
common WLAN scenario, namely a small home area
network or small office network. This can be a WLAN
consisting of two actively transmitting QSTAs and one
actively transmitting QAP, or a WLAN with three
actively transmitting QSTAs. For simplicity, the latter
configuration is explored (Figure 1). The other
scenarios are chosen to represent different WLAN
configurations.
The 802.11 physical layer in the scenarios is based
on the 802.11b standard with a data rate of 11 Mbps,
since this is currently the most used WLAN
technology to our knowledge [12].
Each simulation is executed 32 times, each time
with different seed values to gain statistical
significance in the results. The traffic is constant and is
increased linearly for each class between each set of 32
simulation runs. In all of the simulations the EF, AF
and BE PHBs is mapped as described by Table 1. The
configurations we have used for the scenario are listed
in Table 1.
3000
Link delay
Stabilize time
Simulation duration
Queue length
Physical layer settings
EDCA
parameters
[AIFS,
CWmin,
CWmax, TXOP limit]
Number of stations
EF has configured rate
of 5% of channel rate
(550 Kb/s)
1us
50s
180s
5 packets
802.11b
EF (AC_0) = [2, 3, 7,
1.5]
AF (AC_1) = [2, 7, 15,
3]
BE (AC_3) = [7, 15,
1023, 0]
(3, 5, 8, 12, 16)
4.2. Results
The throughput for the scenario with three stations
is shown in Figure 3. Each sampling is found as the
average of all the simulations for a given offered load.
As the graph shows, the throughput of EF, AF and
BE initially increase linearly up to the point where EF
reaches its configured rate. When EF's offered load has
reached that point, the rate limitation restricts the
offered load, and the EF aggregate is not allowed to
use any more of the bandwidth. The offered load of AF
and BE continue to increase linearly until the point of
channel congestion is reached. After that point AF
continues to increase and BE decreases until BE
reaches zero and AF has all the remaining bandwidth.
When the channel is congested, EF gets its configured
rate, and AF gets the remaining bandwidth at the
expense of BE traffic, which gets close to zero
throughput.
2500
Throughput [Kbps]
Table 1. Detailed configuration for the
scenarios
Parameter
Value
Channel Rate
11 Mbps
Packet size
500 bytes (fixed)
Traffic generator
All nodes sending CBR
traffic
Class configuration
20/30/50 – EF / AF /
BE
2000
1500
1000
500
0
600
2600
4600
6600
8600
10600
12600
14600
Total offered load [Kbps]
EF
AF
BE
Figure 3. Throughput for 3 stations.
AF traffic also have priority over BE and gets all
the remaining bandwidth it requires after EF has
received its allowed rate, as shown in Figure 3. BE
also manages to utilize the remaining traffic from EF
and AF. All this is according to the DiffServ
specifications and the observations are in line with
what could be expected.
EF traffic also has priority over AF, even though it
can not be directly seen from Figure 3. But because of
the EDCA parameters and the 802.11e scheduler [2],
EF traffic has priority over AF. This could easily be
shown by simulations, but have been left out because
of limited space.
Figure 4 presents the latency results when using
three stations. Only EF delay boundaries are evaluated
here, since neither AF nor BE have delay
requirements.
The absolute minimum transmission time for the EF
traffic obtained through simulation was 630us. This
comes close to the value of 576 us calculated as
follows:
Minimum transmission time =
(preamble + PLCP header) /
control rate + ( MAC header + IP packet length)
/ data rate
(4)
where the control rate of 802.11b is 1 Mb/s [12].
The simulation result of 630us is used throughout
the rest of this article as the minimum possible
transmission time. The minimum packet latency is
obtained when the EF packet sees an empty MAC
queue and does not have to wait for another packet in
the queue. Furthermore, the packet is sent out on the
first attempt. When this happens, the minimum latency
gets very close to the minimum transmission time,
because in these simulations the medium propagation
time is set to only 1us. Also, the packet does not have
to wait in the MAC and only have to contend for the
medium one single time.
The maximum latency for an individual packet was
measured to 35.3 ms. This gives an E_p value of E_p =
35.3 ms – 630 us = 34.67ms. This is a fairly high value
for the error term E_p, but it is what the 802.11e
WLAN offers under this scenario. Neither ACK
packets nor SIFS time is included in the maximum
latency calculation.
Table 2. Data from all the latency simulations
Number
of nodes
Min
latency
Max
latency
Avg.
latency
95
percentile
3
0,63 ms
35,3 ms
4,5 ms
11,7 ms
35
5
0,65 ms
47,4 ms
8,1 ms
22,5 ms
30
8
0,68 ms
67,5 ms
14,2 ms
42,1 ms
25
12
0,68 ms
76,5 ms
21,2 ms
53,8 ms
20
16
0,68 ms
86, 9ms
25,8 ms
63,2 ms
Latency for EF packet - 3 nodes scenario
40
Latency [ms]
number of nodes is increasing, as shown by the Table
2, but they increase near linearly. This is not
unexpected, since the probability of traffic collisions is
considerably increased with the number of wireless
stations. This shows that 802.11e adapts well when the
number of stations is considerably increased, and
latency does not rise exponentially.
15
10
5
0
600
5600
10600
Total offered load [Kbps]
Mean
Maximum
Minimum
95 percentile
Figure 4. Latency for 3 stations.
Figure 4 shows the average, minimum, maximum
and 95 percentile for the medium access latency of EF
packets. As can be seen from Figure 4, the average
latency converges to a value of approx. 4.5 ms as the
offered load is increased. The maximum latency,
which measures the latency for the one packet that
experiences the worst-case latency, reaches a
maximum value of 35.3 ms. The maximum latency
seems to increase as the offered load increases, but
stabilizes at around 33 ms. The minimum latency is
stable at 0.63 ms. Figure 4 shows that the average
latency when the offered load is high and the standard
deviation of [4.5, 3.13] ms are well within the E_p
value of 34.67 ms. Because the EF throughput is stable
at the rate R, the EF requirements equations [Eq. (1)
and Eq. (2)] are fulfilled with an E_p value of
34.67ms.
The 95 percentile for the EF packets is also
plotted in Figure 4, and shows that 95% of the packets
are within 11 ms. This is clearly much lower than the
maximum latency, and can be accepted from a wireless
environment.
Because of space limitations, the results from the
other latency simulations are presented in Table 2. All
the measured latency data are increasing when the
The throughput results are also omitted, due to
space limitations. Almost all the throughput results
showed the same pattern as that observed with the
three actively transmitting nodes (Figure 2). The EF
traffic gets the configured rate, while the AF traffic
takes the remaining bandwidth. Thus, the BE traffic
drops close to zero, because all bandwidth are
consumed by the EF and AF traffic.
4.3 Rate configuration
For the scenarios with 12 and 16 stations the
throughput results of the simulations, were not as
expected, though. EF does not get its configured rate,
but converges to a value below this (Figure 5). Here
the configured rate for EF traffic is obviously set too
high. Because of the high number of stations, this leads
to many collisions on the channel. Therefore the actual
throughput for EF traffic becomes lower than the rate
configuration level of 5% of channel rate (550Kbps).
This is clearly not a desired results since it will make
the queue length for EF traffic grow towards
maximum, and latency demands for EF will not be
satisfied (E_p will go towards infinite).
Therefore it is important that the rate configuration
of EF traffic is set at a reasonable level. If the
achievable throughput is higher than the configured
rate, the EF queues will not rise towards maximum,
and EF specifications will be satisfied. This clearly
shows that the rate configuration setting for EF is
strongly dependent on the number of actively
transmitting stations.
The delay bounds for 802.11e's highest priority
class (AC_VO) do follow the DiffServ's EF PHB
specification. The worst case delay bound has been
found by simulation, and the evaluations show that the
AC_VO class is able to meet the EF PHB requirements
for the chosen rate value R. Note however that in order
to fulfill the EF specifications, the rate configuration
for EF must be set correctly and not too high.
Throughput - 16 stations scenario
2000
1800
Throughput [Kbps]
1600
1400
1200
1000
800
600
6. Future Work
400
200
0
480
2480
4480
6480
8480
10480
12480
Total offered load [Kbps]
EF
AF
BE
Figure 5. Throughput for 16 stations.
5. Conclusion
In this paper we have evaluated how the new IEEE
802.11e standard for WLAN QoS is able to
interoperate with DiffServ. This paper contributes with
an architecture for the necessary interoperation
between DiffServ and 802.11e. We also propose a
mapping between DiffServ Per Hop Behavior (PHB)
and 802.11e Access Categories (AC). Furthermore we
evaluate how 802.11e and the proposed mapping are
able to conform to the DiffServ PHB specifications.
Throughput results for the Expedited Forwarding (EF),
Assured Forwarding (AF) and Best Effort (BE) PHB
groups are presented for 5 different WLAN scenarios
with 3, 5, 8, 12 and 16 nodes respectively. Average,
maximum, minimum and 95 percentile latency results
are presented for the EF PHB for the same scenarios.
These evaluations show that the 802.11e WLAN is
able to conform to the PHB specifications under
different conditions, assuming that the rate
configuration is set properly.
The throughput results show that 802.11e conforms
to the DiffServ PHBs, when EF is properly rate
controlled and get the rate that it is supposed to
receive. AF gets priority over BE, and BE drops to
zero if there is not any more available bandwidth. All
this is according to the DiffServ specification.
The mapping however is not according to the
DiffServ specification, since AF only consists of one
drop precedence. The AF PHB specifies that the AF
class should at least implement one AF class with at
least two different drop precedences. At least two drop
precedences must therefore be implemented for
802.11e to be fully DiffServ compatible with respect to
the AF PHBs.
This paper suggests a simple architecture for
DiffServ in 802.11e, but a more comprehensive study
should be done on this subject. The architecture
suggested in this paper does not have DiffServ traffic
conditioner functionality in the QSTAs, and more
work on an architecture that uses this approach should
be done.
Admission control issues are completely left out in
this article, but they are still very important. The
architecture depends heavily on how admission control
is implemented.
It remains to find analytical expressions of the delay
distribution in order to more rigorously determine to
which extent the 802.11e specification conforms to the
DiffServ standard.
In addition, correct setting of the rate limitation of
the EF traffic is needed for fulfillment of the EF PHB
over 802.11e EDCA. This should be investigated more
closely, in order to find precise predictions of how to
set this level.
7. 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] F. Davik and S. Gjessing, ‘Applying the DiffServ
Model to a Resilient Packet Ring Network’, Networking
2005: Proceedings of the 4th International IFIP-TC6
Networking Conference, Waterloo, Canada, May 2-6,
Springer, pages 1461–1464, 2005.
[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] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski,
'Assured Forwarding PHB Group', IETF RFC 2597, June
1999
[6] Dimitris Skyrinaoglou, Nikos Passas, Apostolis
Salkintzis, Evanglos Zervas “A Generic Adaptation Layer
for Differentiated Services and Improved Performance in the
Wireless Networks”
[7] Seyong Park, Kyungtae Kim, Doug C. Kim, Sunghyun
Choi, Sangjin Hong “Collaborative QoS architecture
between DiffServ and 802.11e Wireless LAN”, 2003 IEEE
[8] 'Part 3: Media Acess Control (MAC) Bridges,
ANSI/IEEE Std. 802.1D', IEEE 802.1D, 1998
[9] Xipeng Xiao and Lionel M. Ni., “Internet QoS: A Big
Picture”, IEEE, April 1999
[10] 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
[11] Kevin Fall, Kannan Varadhan, 'The ns Manual',
http://www.isi.edu/nsnam/ns/doc/index.html
[12] Wireless LAN medium access control (MAC) and
Physical layer (PHY) specifications Amendment 2: higherspeed physical layer (PHY)extensions in the 2.4GHz band,
IEEE standard 802.11b-1999