Differentiated Services in e WLANs

Transcription

1 Differentiated Services in e WLANs Bjørn Selvig Simula Reseach Laboratory Aleksander Bai Telenor R&D / Univ. of Oslo aleksab@ifi.uio.no Tor Skeie Fac. of Informatics, Univ. of Oslo tskeie@simula.no Paal Engelstad Telenor R&D / Univ. at Kjeller (UniK) paalee@unik.no Abstract This paper focuses on how the IEEE e 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 e 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 e WLAN environment is first outlined. Then, a mapping scheme from the PHBs to the e priority classes is suggested. How well e EDCA conforms to the DiffServ PHBs are finally evaluated by means of simulations. Keywords: IEEE e, DiffServ, PHB, Quality-of- Service (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 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 e standard was developed in order to meet the QoS requirements in WLANs [2]. The focus in this paper is on the e EDCA, which gives differentiation between four different priority classes called Access Categories (AC). In this paper we address the interoperation of e EDCA and the DiffServ architecture. An evaluation of how well e EDCA conforms to the DiffServ specifications is presented, and a mapping between DiffServ and e 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 e. The reader is pointed to related work concerning the interoperation between DiffServ and e. An architecture for the use of DiffServ in conjunction with e 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 Background 2.1. Differentiated Services (DiffServ)

2 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 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 e IEEE e is a standard for QoS improvements of the MAC layer, approved by IEEE in July 2005 [2] e basically adds priorities to the MAC layer, and provides improvements of the MAC access mechanisms known from the legacy WLAN. The e 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 e structure. Here we have a QAP (QoS enabled Access Point) which is typically connected to other infrastructure like the Internet e nodes, or the QoS enabled stations, are connected to the QAP. This network structure is called QBSS (QoS enabled Basic Service Set) in e and BSS in

3 Figure e 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 e 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 e 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 e network. The QAP in an e 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 Related Work Only few contributions have been published regarding the required interoperation between DiffServ and e, and very little work has been done to evaluate how e 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 e 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 e user priority value. Basically the hierarchical mapping scheme requires DiffServ traffic conditioning functionality at the network layer in the QSTAs in addition to the e 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 e's ACs in the QSTA network layer and relies to a larger extent entirely on e 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 e, so no evaluation regarding e is done. The next section proposes a simple framework for the interoperation between DiffServ and e that improves the disadvantages discussed here. 3. Architecture

4 There are several different ways of making DiffServ and e interoperate. Most approaches in the literature add enhancements to the DiffServ modules or modify the 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 e 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 e by placing all the mapping between e'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 e 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 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 e EDCA. If the module is not placed inside a QAP, the node must implement 802.1D to make the mapping from Ethernet to e. When a packet arrives from a DiffServ edge node, the module will intercept the packet and give it a e 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 e 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 e'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 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 e'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

5 chosen AC is AC_VO, the admission control unit restricts the traffic. The next section will evaluate how well the e'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 e 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 e 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 b 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 e 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 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 e 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 e 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 physical layer in the scenarios is based on the b 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.

6 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 Link delay Stabilize time Simulation duration Queue length Physical layer settings b EDCA parameters [AIFS, CWmin, CWmax, TXOP limit] EF has configured rate of 5% of channel rate (550 Kb/s) 1us 50s 180s 5 packets EF (AC_0) = [2, 3, 7, 1.5] AF (AC_1) = [2, 7, 15, 3] BE (AC_3) = [7, 15, 1023, 0] Number of stations (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. Throughput [Kbps] 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 e 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 b 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

7 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 e WLAN offers under this scenario. Neither ACK packets nor SIFS time is included in the maximum latency calculation. 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 e adapts well when the number of stations is considerably increased, and latency does not rise exponentially. Table 2. Data from all the latency simulations Number of nodes Min latency Max latency Avg. latency 95 percentile Latency for EF packet - 3 nodes scenario 3 0,63 ms 35,3 ms 4,5 ms 11,7 ms 5 0,65 ms 47,4 ms 8,1 ms 22,5 ms 8 0,68 ms 67,5 ms 14,2 ms 42,1 ms Latency [ms] ,68 ms 76,5 ms 21,2 ms 53,8 ms 16 0,68 ms 86, 9ms 25,8 ms 63,2 ms 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 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.

8 Throughput [Kbps] Throughput - 16 stations scenario The delay bounds for e'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. 6. Future Work 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 e standard for WLAN QoS is able to interoperate with DiffServ. This paper contributes with an architecture for the necessary interoperation between DiffServ and e. We also propose a mapping between DiffServ Per Hop Behavior (PHB) and e Access Categories (AC). Furthermore we evaluate how e 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 e 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 e 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 e to be fully DiffServ compatible with respect to the AF PHBs. This paper suggests a simple architecture for DiffServ in e, 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 e 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 e 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 , [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

9 [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 e Wireless LAN, 2003 IEEE [8] 'Part 3: Media Acess Control (MAC) Bridges, ANSI/IEEE Std D', 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 e EDCF Simulation Model in ns-2.26', Technical University Berlin, Telecommunications Networks Group, Berlin November 2003 [11] Kevin Fall, Kannan Varadhan, 'The ns Manual', [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 b-1999