1 / 32

Methods for providing Quality of Service in WLANs

Methods for providing Quality of Service in WLANs. W.Burakowski, A . Beben , J.Sliwinski Institute of Telecommunications, Warsaw University of Technology, Poland. Outline. Class of Service (CoS) concept for providing end_to_end QoS in heterogeneous and multi-domain networks

jfranqui
Download Presentation

Methods for providing Quality of Service in WLANs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Methods for providing Quality of Service in WLANs W.Burakowski, A. Beben, J.Sliwinski Institute of Telecommunications, Warsaw University of Technology, Poland

  2. Outline • Class of Service (CoS) concept for providing end_to_end QoS in heterogeneous and multi-domain networks • How to provide CoSs in WLANs • Method for improving packet delay characteristics in WLANs • Summary COST 279 Final Seminar, Lisbon, 27-29 June 2005

  3. Problem statement • Objective: Assuring strict end_to_end QoS guarantees at the packet layer • Network environment: heterogeneous and multi-domain networks • Different access network technologies:WiFi, xDSL, UMTS, LAN/Ethernet • IP core • To follow concept of Classes of Service (acc. to the IETF proposal) „Service class” represents a set of traffic that requires specific delay, loss and jitter characteristics from the network for which a consistent and defined per hop-behaviour applies COST 279 Final Seminar, Lisbon, 27-29 June 2005

  4. CoSs: IETF proposal (1) 11 Basic CoSs and 4 aggregated CoSs COST 279 Final Seminar, Lisbon, 27-29 June 2005

  5. CoSs: IETF proposal (2), exemplary applications COST 279 Final Seminar, Lisbon, 27-29 June 2005

  6. Exemplary set of CoSs Basic CoSs – visible by the users and can be deployed in some access networks (e.g. in LAN/Ethrenet) Aggregated CoSs – can be deployed in some parts of the networks (e.g. WLANs, inter-domain links) COST 279 Final Seminar, Lisbon, 27-29 June 2005

  7. CoSs: An example of deployment in network COST 279 Final Seminar, Lisbon, 27-29 June 2005

  8. CoSs: An example of deployment in network COST 279 Final Seminar, Lisbon, 27-29 June 2005

  9. Access Point Edge Router Ethernet xDSL Cable Possible bottlenecks CoSs in WLANs (1) COST 279 Final Seminar, Lisbon, 27-29 June 2005

  10. CoSs in WLANs: status WLAN Standard IEEE 802.11 Currently available Near future: 802.11e (September 2005 ?) DCF PCF EDCA HCCA • - no QoS • - contention based operation • widely deployed • irregular polling • no equipment • not deployed (!) - relative QoS - just hitting the market • polling based • available in long term DCF – Distributed Coordination Function PCF – Point Coordination Function EDCA - Enhanced Distributed Channel Access HCCA - Hybrid Coordinated Channel Access COST 279 Final Seminar, Lisbon, 27-29 June 2005

  11. CoSs in WLANs: status Investigated approaches for handling QoS traffic in WLANs: • Tuning of MAC parameters to get „a priority” of QoS traffic over the best effort • Enhancement of MAC layer for improving polling mechanism Any of the proposed approaches is not sufficient for supporting CoSs COST 279 Final Seminar, Lisbon, 27-29 June 2005

  12. CoSs in WLANs: Mechanisms in 802.11 • DCF access • Distributed, random, contention based access • Assures „equal” access to medium No traffic differentiation, no QoS guaranties – a single best effort service COST 279 Final Seminar, Lisbon, 27-29 June 2005

  13. Proposed solution (1) • Use 802.11 DCF mode COST 279 Final Seminar, Lisbon, 27-29 June 2005

  14. Proposed solution (1) • Use 802.11 DCF mode • To separate in a physical way the QoS traffic from the best effort traffic by keeping two APs – one for QoS traffic and one for best effort traffic COST 279 Final Seminar, Lisbon, 27-29 June 2005

  15. Proposed solution (2) General strategy: • Terminal has access to 2 associated APs • One for BE traffic • One for QoS traffic (RT and N-RT) • Problems to be solved: • Switching between APs • Differentiation between „real” and „non-real” time traffics • How to perform admission control COST 279 Final Seminar, Lisbon, 27-29 June 2005

  16. Connection scenario WiFi-QoS topology Router RM SIP proxy Switch HUB AP-BE AP-QoS T T T T T RM – Resource Manager

  17. Connection scenario Terminal sends by AP-BE its QoS request to SIP Proxy Router SIP proxy Switch HUB RM AP-BE AP-QoS QoS request T T T T T

  18. Connection scenario SIP Proxy sends the QoS request to RM where CAC is performed Router RM QoS request SIP proxy Switch HUB AP-BE AP-QoS T T T T T

  19. Connection scenario Router RM RM reads the MAC address Switch HUB AP-BE AP-QoS T T T T T

  20. Connection scenario Router RM Switch HUB RM adds the MAC address to „allowed” list AP-BE AP-QoS T T T T T

  21. Connection scenario Router RM RM adds the MAC address to „denied” Switch HUB AP-BE AP-QoS T T T T T

  22. Connection scenario Terminal is attached to the AP-QoS and QoS confirmation is send Router RM QoS confirmation Switch HUB AP-BE AP-QoS T T T T T

  23. Traffic handling: Differentiation of RT and NRT • The bottleneck is DOWNLINK only • Need to implement QoS mechanisms on the top of MAC: • Separate queues for RT and NRT • Policers (RT) and shapers (NRT) • Admission Control COST 279 Final Seminar, Lisbon, 27-29 June 2005

  24. Admission Control • Engineering approach • The main idea: WLAN is stable until the offered load does not exceed serving capabilities PPS – Packets per second COST 279 Final Seminar, Lisbon, 27-29 June 2005

  25. Simulation results (1) • Single APQOS with a number of terminals • Two types of streams: • RT service: symmetrical voice connection G.729 codec; 20 ms packet inter-arrival time (50 pkt/s) for each direction; 60 bytes packets (IP+UDP+RTP+payload). • NRT service: Greedy TCP flows in downstream direction only, 512 kbit/s shaped throughput; COST 279 Final Seminar, Lisbon, 27-29 June 2005

  26. (a) average delay (b) 99.9% quantile of IPDV Simulation results (2) Acceptance region Conclusions: • Relatively large delay variation is caused by „random access” mechanism in MAC • To fulfill e2e QoS requirements additional mechanism may by required! COST 279 Final Seminar, Lisbon, 27-29 June 2005

  27. Method for improving delay characteristics in WLANs (1) • Delay variation in WLANs is caused by transmission backoffs and collisions coming from MAC protocol behaviour • To overcome we need synchronisation between streams, like in TDMA COST 279 Final Seminar, Lisbon, 27-29 June 2005

  28. Method for improving delay characteristics in WLANs (2) • The „self synchronisation” mechanism enforces synchronization between CBR sources by introducing for each CBR stream different initial delay dDi • The value of dDi is fixed independently in each station based on the last successful transmission as the interval between the moment when packet transmission starts and the moment of its arrival COST 279 Final Seminar, Lisbon, 27-29 June 2005

  29. Simulation results (1) • Single APQOS with a number of terminals • Only VoIP streams: • RT service: symmetrical voice connection G.729 codec; 20 ms packet inter-arrival time (50 pkt/s) for each direction; 60 bytes packets (IP+UDP+RTP+payload). COST 279 Final Seminar, Lisbon, 27-29 June 2005

  30. Simulation results (2) standard WLAN enhanced WLAN Conclusion: The method assures constant delay! Histogram of the transfer delay differences between two consecutive packets after synchronisation phase (11 VoIP streams) COST 279 Final Seminar, Lisbon, 27-29 June 2005

  31. Numerical results (3) VoIP streams start transmission at the random moments Cumulative distribution function of the synchronization time VoIP streams start transmission at the same time (worst case) Conclusion: For the random start synchronization is reached quickly COST 279 Final Seminar, Lisbon, 27-29 June 2005

  32. Summary • Providing e2e QoS requires to assure QoS in each part of the network • The concept of CoSs is exploited • Providing CoSs in WLANs requires: • Separation between QoS and best effort traffics • Additional traffic handling mechanisms • Application of admission control • The solution is verified by simulation and is planned for implementation • We can get excellent delay charactaristics for VoIP by adding „self synchronisation” mechanism COST 279 Final Seminar, Lisbon, 27-29 June 2005

More Related