Product Development

Inside Whitepaper

• Abstract
• Introduction
• Extending reservation based end-to-end QoS to WLAN
• Abbreviations and acronyms
• References
• NOTES

• Home
• » Whitepapers
• » Extending End-to-End QoS to WiFi based WLAN

Extending End-to-End QoS to WiFi based WLAN

Abstract

Applications such as VoIP, IPTV, VoD have very different requirements on the network traffic compared to the traditional interactive and background applications. IEEE standard 802.11e addresses these QoS requirements in a WiFi based WLAN. It provides enhancements to the MAC layer protocol for supporting both prioritized and parameterized traffic between a QSTA and a QAP. To address the end-to-end QoS needs, the link level QoS supported by 802.11e standard should be used in conjunction with existing end-to-end QoS mechanisms such as RSVP and SIP/SDP. Here we propose a mechanism to extend the end-to-end QoS into the WiFi based WLAN.

Introduction

The last few years have witnessed tremendous growth in the use of WiFi based WLAN for multimedia applications such as VoIP, VoD and Internet Radio. The characteristics of the data traffic for these applications are very different from the traditional internet traffic. For example VoD requires high bandwidth while VoIP is burst in nature and requires low delay and jitter. As a result, to ensure a high level of user experience, these traffic types need to be treated differently than the traditional internet traffic. Further, the available bandwidth in the WiFi based WLAN is also limited. Thus it is very essential to manage the access to the WiFi based WLAN resources and prioritize the traffic to ensure appropriate quality of service (QoS) to different kinds of traffic. IEEE 802.11e standard addresses the link level (between a station and an access point) QoS in a wireless local area network (WiFi based WLAN).

The IEEE 802.11e standard enhances the MAC (Media Access Control) layer protocol to support QoS in a WiFi based WLAN. The standard provides two approaches - Prioritization of Traffic and Parameterization of traffic. In the traffic prioritization approach, the traffic is classified into one of the four categories - Voice, Video, Best Effort and Background. The transmission is done using Enhanced Distributed Channel Access (EDCA) mechanism (see NOTE 1 for more details). The EDCA parameters for the four categories of traffic are adjusted appropriately to match the requirements of those categories of traffic.

The second approach lets us define traffic streams with appropriate traffic parameter values (such as mean and peak bandwidth, burst rate). This approach is called the Hybrid Control Function (HCF) Controlled Channel Access (HCCA) approach (for details see NOTE 2). In this approach, the access point will control the medium and assign transmit opportunities to the stations based on the agreed upon traffic specification (TSPEC) parameters. The standard lets both of these approaches to be used together in a basic service set (BSS).

Another important feature supported in the standard is the admission control for both prioritized and parameterized traffic (for details see NOTE 3). To facilitate admission control, the standard lets one to apply TSPECs to both kinds of traffic. When traffic streams with appropriate TSPECs are setup, a QAP will admit only the traffic that satisfies the TSPECs. TSPECs can also be used to describe power saver option and security options. At present most of the QoS solutions for the WiFi based WLAN are based on the traffic prioritization approach - these solutions are based on the subset of the standard called Wireless Multimedia (WMM).

As mentioned earlier, the QoS capabilities of IEEE 802.11e standard provides QoS on a per-link basis in a WiFi based WLAN. Using this capability existing end-to-end QoS frameworks can be extended to provide quality service to WiFi customers. In general there are two approaches for providing end-to-end QoS - one using differentiated services and the other based on resource reservation. The first approach marks the traffic with appropriate type of service (TOS) field based on the category of the traffic. This approach is simple, but does not guarantee QoS. In this paper, we outline an approach to extend the reservation based end-to-end QoS to the WiFi based WLAN.

Extending reservation based end-to-end QoS to WiFi based WLAN

The approach that we propose involves using a QoS Manager through which the reservation requests coming to or generating from the WiFi based WLAN are route. The QoS manager will map the QoS parameters in the reservation request to appropriate 802.11e TSPEC parameters. This mapping is achieved both using automatic mapping to 802.11e TSPEC parameters using appropriate algorithms wherever possible and using user configurable values for the rest of the 802.11e TSPEC parameters. The QoS manager will also interface with the Authorization and authentication server (such as Diameter or Radius server) to validate the request. If the request is properly authenticated and authorized to access the service, the QoS manager will use the mapped TSPECs to setup a traffic stream between the end point QSTA (QoS enabled station) and the QAP (QoS enabled access point). Any failure to setup such a traffic stream will be treated as a reservation failure and appropriate failure message is sent to the source of the request. The proces s at the QoS manager is the same whether the reservation request is sent by the WiFi based WLAN or received by the WiFi based WLAN. Figures 1 and 2 illustrate this process.

Figure 1. WLAN with QoS Manager, Receiver in WLAN

Figure 2. WLAN with QoS Manager, Sender in WLAN

Following sections describe how this approach can be used specifically for RSVP based end-to-end QoS framework and for SIP/SDP based end-to-end framework.

Extending RSVP based end-to-end QoS

RSVP uses the PATH messages sent from the sender towards the receiver and the RESV messages sent from the receiver towards the sender to communicate the QoS requirements to all the nodes between the sender and the receiver(s). The sender-Tspec and ADSPEC in the PATH message or the flowspec (consisting of Tspec and Rspec) in the RESV message can be used to derive values for the 802.11e TSPEC parameters. To do this, the router is configured such that the RSVP messages addressed to the WiFi based WLAN elements are forwarded to the QoS Manager.

Receiver in the WiFi based WLAN

When the receiver is in the WiFi based WLAN, the QoS Manager will use the sender-Tspec in the received PATH message to determine the values for the 802.11e TSPEC parameters. After performing the required authentication and authorization, the TSPECs is sent to the end-point QSTA for setting up a traffic stream as per 802.11e specifications. It is assumed that the QSTA (or the fully 802.11e compliant dirver at the QSTA) will provide means of setting up of traffic streams. When the traffic stream is successfully setup, the QoS manager will construct RESV message with appropriate flowspec and propagate it towards the sender.

Figure 3. end-to-end QoS using RSVP, Receiver in WLAN

Sender in the WiFi based WLAN

Figure 4. end-to-end QoS using RSVP, Sender in WLAN

When the sender is in the WiFi based WLAN, the sender will initiate a PATH message which will be forwarded towards the receiver by the router. Later, when the RESV message comes for the sender, router will forward it to the QoS Manager. Now, the QoS manager will calculate the 802.11e TSPECs based on the Tspec and Rspecs in the RESV request and send a request to the QSTA to create a traffic stream with this TSPEC. In this case, the sender QSTA should have user agent capable of initiating an RSVP session.

802.11e TSPEC parameters

Following table shows important 802.11e TSPEC parameters and the RSVP flowspec parameters from which they can be derived.

Extending SIP/SDP based end-to-end QoS

SIP follows a simple offer/answer model of exchanging SDP payloads. When the end-to-end QoS signaling is done using SIP/SDP, the SDP payload in the SIP INVITE and 200-OK messages contains information about the session and the media. This information can be used to generate 802.11e QoS parameters for the QSTA. The SIP Proxy server is configured to forward the SIP/SDP messages (addressed to the WiFi based WLAN elements) to the QoS manager.

Receiver in the WiFi based WLAN

The SIP Proxy will forward the INVITE message to the QoS Manager. Using informations such as the media type, codecs, ports, protocol, bandwidth contained in the message the Qos Manager will generate the required 802.11e TSPECs. This TSPECs is sent to the QSTA for setting up a traffic stream. If the traffic stream is setup successfully, the QoS Manager will send a SIP 200-OK message to the sender.

Figure 5. end-to-end QoS using SIP/SDP, Receiver in WLAN

Sender in the WiFi based WLAN

In this case the sender QSTA should contain a user agent (UA) capable of generating SIP/SDP session requests. The SIP Proxy forwards the INVITE message from the QSTA to the receiver. Later, when the SIP 200-OK message addressed to the QSTA is received, the SIP Proxy will forward it to the QoS Manager instead. The QoS manager will use the session and media information from the message to derive the 802.11e TSPECs. It will then send the TSPECs to the QSTA for creating appropriate traffic stream. When the traffic stream is created successfully, QoS manager will forward the SIP 200-OK message to the QSTA.

Figure 6. end-to-end QoS using SIP/SDP, Sender in WLAN

802.11e TSPEC parameters

The media specification in the SDP message contains information about the media type, port(s) used, protocol and codec information. Other useful information in the SDP message are the bandwidth, video framerate etc. These are useful in generating appropriate values for 802.11e TSPEC parameters. PacketCable specifications (PacketCableT Audio/Video Codecs Specification) have come up with appropriate values for RSVP flowspec parameters for various audio/video codecs. Using this information we can derive values for 802.11e TSPEC parameters.

Abbreviations and acronyms

References

NOTES

1. Traffic Prioritization in 802.11e

Each QSTA in a QoS enhanced basic service set (BSS), contains a hybrid coordination function (HCF). Under HCF, the basic unit of allocation for the right to transmit is called the TXOP (Transmission Opportunity). Each TXOP has a starting time and a maximum duration. The HCF has two modes of operation - EDCA and HCCA. The prioritization of traffic is achieved using the EDCA (Enhanced Distributed Channel Access) mode. This is a contention-based channel access i.e., a QSTA obtains an opportunity to transmit by contending with other QSTAs for the medium and winning it. Each time slot is divided into two - a contention period and a contention-free period. EDCA mode can be used only during the contention period. As mentioned earlier, EDCA provides traffic prioritization based on eight User Priority (UP) values (0 to 7). The UP values are mapped to four access categories - AC_BK, AC_BE, AC_VI, and AC_VO. The user priorities are same as that mentioned in the 802.1D standard. Following table shows how User Priorities are mapped to different access categories (AC).

The differentiation in QoS for different ACs is achieved by varying the values for the following EDCA parameters:

2. Parameterized QoS in 802.11e

Parameterized QoS is supported in 802.11e standard using the HCCA component of the HCF. In this mechanism, the QAP contains a Hybrid Coordinator (HC) that has a higher medium access priority than the non-AP QSTAs (a QSTA that is not an access point). This allows HC to gain control of the wireless medium more often. When HC gains control of the medium, either it transmits data to the non-AP QSTAs or it grants TXOP to non-AP QSTAs for transmitting data based on the traffic streams that have been already setup. Traffic streams with required traffic specifications (TSPEC parameters) can be setup between a QSTA and a QAP using the enhancements provided for the MAC layer in the 802.11e standard. The ADDTS, DELTS requests are used to setup and tear down traffic streams. Setting up of traffic streams are initiated by the non-AP QSTA with an ADDTS request to the QAP. When the QAP admits a traffic stream, it will reserve the resources required for the traffic stream (as specified in the TSPEC).

802.11e standard allows up to 8 uplink traffic streams and 8 downlink or sidelink (to other QSTAs in the same QBSS) traffic streams per non-AP QSTA. Since each uplink/sidelink traffic stream needs its own transmit queue, the resources such as memory required for parameterized QoS can be much higher compared to EDCA based prioritized QoS.

3. Admission Control

802.11e QoS standard supports admission control for the traffic between a QSTA and a QAP. Admission control is handled using TSPEC negotiation and traffic stream setup. Admission control can be used for both EDCA and HCCA traffic. Since the availability of bandwidth is limited in the wireless medium, admission control becomes very important to control access to the medium and for the efficient use of the available bandwidth.

In case of EDCA, the QAP indicates if admission control is required for a particular AC when it sends the EDCA parameters to the QSTA. When admission control is required for a particular AC, QSTA needs to setup a traffic stream for this AC by sending a ADDTS request to the QAP. The QAP will respond with a ADDTS response indicating whether the traffic stream is admitted or not. After successfully setting up of a TS (traffic stream), the non-AP QSTA can use the EDCA parameters for the AC to obtain TXOPs.

Admission control for HCCA traffic is based on the negotiated TSPEC parameters during the setting up HCCA traffic streams. If the HC (of QAP) admits a TS, then it will schedule channel access to this TS based on the TSPEC parameters.

Copyright © 2010 Calsoft Labs Incorporated

• Terms Of Use
• Privacy policy
• Sitemap