Guest

Cisco Aironet 1200 Series

Wireless Quality-of-Service

 Feedback

Deployment Guide


Wireless Quality-of-Service
Deployment Guide


This deployment guide describes the implementation of wireless quality of service (QoS) over the 802.11 interfaces for Cisco Aironet®1200, 1100, 350, and 340 Series Access Points and the Cisco Aironet 350 Series Wireless Bridge. Key 802.11 QoS concepts, features, and guidelines for deploying wireless QoS are introduced and discussed in this guide.

1  Introduction to QoS

QoS refers to the capability of a network to provide better service to selected network traffic over various network technologies. QoS technologies provide the elemental building blocks for business multimedia and voice applications used in campus, WAN, and service provider networks. QoS allows network managers to establish service-level agreements (SLAs) with their network users.

QoS enables network resources to be shared more efficiently and expedites the handling of mission-critical applications. QoS manages time-sensitive multimedia and voice application traffic to ensure that this traffic receives higher priority, greater bandwidth, and less delay than best-effort data traffic. With QoS, network managers can manage bandwidth more efficiently across LANs and WANs.

QoS provides enhanced and predictable network service in the following ways:

  • Supporting dedicated bandwidth for critical users and applications
  • Controlling jitter and latency (required by real-time traffic)
  • Managing and minimizing network congestion
  • Shaping network traffic to smooth the traffic flow
  • Setting network traffic priorities

1.1  Wireless QoS Deployment Schemes

In the past, wireless LANs (WLANs) were used to transport low-bandwidth, data application traffic. Today, with the expansion of WLANs into enterprise and vertical (retail, finance, education) markets, WLANs are now used to transport high-bandwidth, intensive data applications in conjunction with time-sensitive multimedia applications. This requirement has led to the necessity for wireless QoS.

Several vendors support proprietary wireless QoS schemes for voice applications. To speed up the rate of QoS adoption and to support multi-vendor, time-sensitive applications, a unified approach to wireless QoS is needed. The IEEE 802.11e working group within the IEEE 802.11 standards committee is working on a wireless QoS standard that is expected to be finalized in 2003. Cisco Aironet products support QoS based on the IEEE 802.11e Draft standard specifications as of November 2002. Cisco IOS® Software Release 12.2(4)JA for the Cisco Aironet 1100 Series Access Point and Cisco Aironet VxWorks Firmware Release 12.00T or later for Cisco Aironet 1200, 350, and 340 Series Access Points and the 350 Series Wireless Bridge support IEEE 802.11e enhanced distributed coordination function (EDCF)-based wireless QoS. Figure 1 shows an example deployment of wireless QoS based on Cisco IOS Software and VxWorks features.


Figure 1 Wireless QoS Deployment Example

1.2  QoS Parameters

QoS is defined as the measure of performance for a transmission system that reflects its transmission quality and service availability. Service availability is a crucial foundational element of QoS. Before QoS can be successfully implemented, the network infrastructure must be highly available. The network transmission quality is determined by the following factors:

  • Latency
  • Jitter
  • Loss

1.2.1  Latency

Latency (or delay) is the amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. This time period is termed the "end-to-end delay" and can be broken into two areas: fixed network delay and variable network delay.

Fixed network—delay includes encoding/decoding time (for voice and video), as well as the finite amount of time required for the electrical or optical pulses to traverse the media in route to their destination.

Variable network—delay generally refers to network conditions, such as congestion, that may affect the overall time required for transit.

1.2.2  Jitter

Jitter (or delay-variance) is the difference in the end-to-end latency between packets. For example, if one packet requires 100 milliseconds (ms) to traverse the network from the source-endpoint to the destination-endpoint and the following packet requires 125 ms to make the same trip, then the jitter is calculated as 25 ms.

1.2.3  Loss

Loss (or packet-loss) is a comparative measure of packets faithfully transmitted and received to the total number that were transmitted. Loss is expressed as the percentage of packets that were dropped.

1.3  Downstream and Upstream QoS

Figure 2 illustrates the definition of QoS radio "upstream" and "downstream."


Figure 2 Upstream and Downstream QoS Definitions

  • Radio downstream QoS refers to the traffic leaving the access point and traveling to the WLAN clients. Radio downstream QoS is the primary focus of this deployment guide.
  • Radio upstream QoS refers to traffic leaving the WLAN clients and traveling to the access point. No vendor support is currently available for radio upstream QoS features for WLAN clients. This support is specified in the 802.11e Draft, but has not yet been implemented.
  • Ethernet downstream refers to traffic leaving the switch or router traveling to the access point. QoS may be applied at this point to prioritize and rate-limit traffic to the access point. Configuration of Ethernet downstream QoS is not discussed in this deployment guide.
  • Ethernet upstream refers to traffic leaving the access point traveling to the switch. The access point classifies traffic from the access point to the upstream network.

1.4  QoS and Network Performance

The application of QoS features may not be easily detected on a lightly loaded network. Indeed, if latency, jitter, and loss are noticeable when the media is lightly loaded it is as an indication of a system fault or that an application's latency, jitter, and loss requirements are not a good match for the network.

QoS features start to impact application performance as the load on the network increases. QoS works to keep the latency, jitter, and loss for selected traffic types within acceptable bounds.

By providing downstream prioritization from the access point, upstream client traffic is treated as best effort. A client has to compete with other clients for (upstream) transmission as well as competing with best-effort (downstream) transmission from the access point. Under certain load conditions, a client can experience upstream congestion and the performance of QoS sensitive applications may be unacceptable despite the QoS features on the access point.

1.5  Deployment Guide Overview

Section 2 of this document discusses the current implementation of distributed coordination function (DCF) as specified by the 802.11 standard. In Section 3, EDCF implementation as specified by the 802.11e working group is discussed in detail. 802.11e EDCF-based QoS implementation details in VxWorks and Cisco IOS Software operating systems are discussed in detail in Sections 4 and 5. Finally, Section 6 provides guidelines for deploying wireless QoS.

2  802.11 DCF

Data frames in 802.11 are sent using the DCF. The DCF is composed of two main components:

  • Interframe space (IFS)
  • Random backoff (contention window)

DCF is used in 802.11 networks to manage access to the radio frequency medium. A baseline understanding of DCF is necessary in order to deploy 802.11e-based EDCF. Please read the IEEE 802.11 specification for more information on DCF.

2.1  Interframe Spaces (SIFS, PIFS, and DIFS)

Interframe spaces (Figure 3) allow 802.11 to control which traffic gets first access to the channel once carrier sense declares the channel to be free.


Figure 3 Interframe Spaces (IFSs)

1

802.11 currently defines three interframe spaces:

  • Short interframe space (SIFS) 10 µs
  • Point (coordination function) interframe space (PIFS) SIFS + 1 x slot time = 30 µs
  • Distributed (coordination function) interframe space (DIFS) 50 µs SIFS + 2 x slot time = 50 µs

2.1.1  SIFS

Important frames such as acknowledgments wait the SIFS before transmitting. There is no random backoff when using the SIFS, as frames using the SIFS are used in instances where multiple stations would not be trying to send frames at the same time. The SIFS provides a short and deterministic delay for packets that must go through as quickly as possible. The SIFS is not available for use by data frames. Only 802.11 management and control frames use SIFS.

2.1.2  PIFS

An optional portion of the 802.11 standard defines priority mechanisms for traffic that uses PIFS. There is no random back mechanism associated with PIFS, as it relies upon a polling mechanism to control which station is transmitting. The option is not widely adopted2 due to the associated overhead, and lack of flexibility in its application.

2.1.3  DIFS

Data frames wait for the DIFS before beginning the random backoff procedure that is part of the DCF. This longer wait ensures that traffic using the SIFS or PIFS timing will always get an opportunity to send before any traffic using the DIFS attempts to send.

2.2  Random Backoff

When a data frame using DCF is ready to be sent, it goes through the following steps.


Step 1.   Generate a random backoff number between 0 and a minimum contention window (CWmin)

Step 2.   Wait until the channel is free for a DIFS interval

Step 3.   If the channel is still free, begin decrementing the random backoff number, for every "slot time" (20 µs) the channel remains free.

Step 4.   If the channel becomes busy (another station got to 0 before your station) decrementing stops and steps 2 to 4 are repeated.

If the channel remains free until the random backoff number reaches 0, the frame may be sent.

Figure 4 shows a simplified3 example of how the DCF process works:

  • Station A has successfully sent a frame, and three other stations also wish to send frames but must defer to Station A's traffic.
  • Upon Station A complete transmission, all the stations must still defer for the DIFS. Once the DIFS is complete, stations wishing to send a frame can begin decrementing their backoff counter, once every slot time, and may send their frame.
  • Station B's backoff counter reaches zero before Stations C and D, and therefore Station B begins transmitting its frame.
  • Once Station C and D detect that Station B has begun transmission they must stop decrementing their backoff counters and again defer until the frame has been transmitted and a DIFS has passed.
  • During the time that Station B is transmitting a frame, Station E gets a frame to transmit, but as Station B is sending a frame it must defer in the same manner as Stations C and D.
  • Once Station B completes transmission and the DIFS has passed stations with frames to send, begin decrementing their backoff counters again. In this case Station D's backoff counter reaches zero first and it begins transmission of its frame.
  • The process continues as traffic arrives on different stations.

Figure 4 Distributed Coordination Function (DCF) Example

2.2.1  CWmin, CWmax, and Retries

DCF uses a contention window (CW) to control the size of the random backoff. The contention window is defined by two parameters:

  • aCWmin
  • aCWmax

The random number used in the random backoff is initially a number between 0 and aCWmin. If the initial random backoff expires without successfully sending the frame, the station or access point increments the retry counter, and doubles the value random backoff window size. This doubling in size will continue until the size equals aCWmax. The retries continue until the maximum retries or time to live (TTL) has been reached. This process of doubling the backoff window is often referred to as a binary exponential backoff, and is illustrated in Figure 5.


Figure 5 Growth in Random Backoff Range with Retries

3  IEEE 802.11e

This section discusses 802.11e EDCF-based QoS implementation and QoS advertisements by WLAN infrastructure.

3.1  EDCF

The current IEEE 802.11e Draft contains EDCF. This is the feature supported in this access point code release. The EDCF is an enhancement of the DCF described above. The enhancement is the adjustment of the variable CWmin and CWmax random backoff values based upon traffic classification. Figure 6 shows the different settings for the CWmin and CWmax of each traffic class as illustrated by Cisco Aironet software. These figures are based on those proposed in the 802.11e Draft.


Note:    Do not alter these settings for production networks without significant tests specific to the applications in question. For example, having a CWmax value less that the CWmin of another class may cause "starvation" of that other traffic class, as the worst-case random backoff of the preferred class would be better than the best-case random backoff of the less favored class. It should also be noted that the traffic has already been queued based upon its traffic classification by the access point before the CWmin and CWmax values are applied at the radio.



Figure 6 Default CWmin and CWmax Values of Different Traffic Categories

Figure 7 shows the principle behind different CWmin values per traffic classification. All traffic waits the same DIFS, but the CWmin value used to generate the random backoff number depends upon the traffic classification. High-priority traffic has a small CWmin value, giving a short random backoff, whereas best-effort traffic has a large CWmin value that on average gives a large random backoff number.


Figure 7 EDCF Random Backoff and Traffic Classification

Figure 8 shows an example of how the different CWmin values impact traffic priority.

  • While Station X is transmitting its frame, three other stations find that they needed to send a frame. Each station has to defer while a frame is already being transmitted, and each station generates a random backoff.
  • Because stations Voice 1 and Voice 2 have a traffic classification of voice, they use an initial CWmin of three, and therefore have short random backoff values. Best Effort 1 and Best Effort 2 generate longer random backoff times, because their CWmin value is 31.
  • Station Voice 1 has the shortest random backoff time, and therefore starts transmitting first. When Voice 1 starts transmitting all other stations defer. While station Voice 1 is transmitting, station Voice 3 finds that it needs to send a frame, and generates a random backoff number, but defers due to station Voice 1's transmission.
  • Once station Voice 1 has finished transmitting, all stations wait the DIFS, and then being decrementing their random backoff counters again.
  • Station Voice 2 completes decrementing its random backoff counter first and begins transmission. All other stations defer.
  • Once station Voice 2 has finished transmitting, all stations wait the DIFS, and then being decrementing their random backoff counters again.
  • Best Effort 2 completes decrementing its random backoff counter first and begins transmission. All other stations defer. This happens even though there is a voice station waiting to transmit. This shows that best-effort traffic will not be "starved" by voice traffic as the random backoff decrementing process will eventually bring the best-effort backoff down to similar sizes as high-priority traffic, and that the random process may, on occasion, generate a small random backoff number for best-effort traffic.
  • Once Best Effort 2 has finished transmitting, all stations wait the DIFS, and then begin decrementing their random backoff counters again.
  • Station Voice 3 completes decrementing its random backoff counter first and begins transmission. All other stations defer.
  • The process continues as other traffic enters the system.

Figure 8 Impact of Traffic Classification Example

The overall impact of the different CWmin and CWmax values is difficult to show well in the timing diagrams used thus far, because their impact is more statistical in nature. It is simpler to compare two examples, and show the impact of these different values in the average times that should be generated by the random backoff counters.

If we compare interactive voice and interactive video, these traffic categories have CWmin values of 3 and 15, and CWmax values of 32 and 63 respectively. This gives the averages for the random backoff counters shown in Table 1.

Table 1   Random Backoff Averages

CWmin CWmax Average Minimum Average Maximum
Interactive voice

3

31

1.5

15.5

Interactive video

15

63

7.5

31.5

Best effort

31

255

15.5

127.5

These averages show that an interactive voice frame would only have an average random backoff time of 30 µs, whereas the average random backoff time for interactive video frame would be 150 µs. If interactive voice and interactive video stations began trying to transmit at the same time the interactive voice frame would normally be transmitted first, and with a very small delay.

The average maximum gives an indication of how quickly and how large the random backoff counter would grow in the event of a retransmission. The smaller the average maximum value indicates how aggressive traffic classification behaves. No matter how many times it has retried, interactive voice's random backoff delay should not, on average, be above that of the minimum delay of best-effort traffic. This means that average worst-case backoff delay for interactive voice traffic would on average be the same as the average best case for best-effort traffic.


Note:    In this EDCF implementation, all WLAN clients are treated equally for upstream transmission (from the WLAN clients to the access point) unless a client (example: SpectraLink voice over IP [VoIP] device) implements a proprietary mechanism of obtaining the channel more quickly than the others.


3.2  QoS Advertisements by WLAN Infrastructure

The WLAN infrastructure devices (such as an access point) advertise their QoS parameters. WLAN clients with QoS requirements use these advertised QoS parameters to determine which is the best access point to associate with.

Cisco Aironet Software Release 12.00T for VxWorks access points and bridges and Cisco IOS Software release 12.2(4)JA for Aironet 1100 Series Access Points support two mechanisms to advertise QoS parameters:

  • Symbol Technologies, Inc. Extensions (Symbol NetVision handsets only)
  • QoS basis service set (QBSS): Based on IEEE 802.11e Draft version 3.3

Figure 9 shows the QBSS information element (IE) advertised by a Cisco access point. The channel utilization field indicates the portion of available bandwidth currently used to transport data within the WLAN. The frame loss-rate field indicates the portion of transmitted frames that require retransmission or are discarded as undeliverable.


Figure 9 QBSS Information Element (IE) Implementation: IEEE 802.11e Draft Version 3.3
Element ID

(11)

Length

(6)

Station Count

(2 octets)

Channel Utilization

(1 octet)

Frame Loss Rate

(1 octet)

Figures 10 and 11 illustrate the mechanism for enabling QoS advertisements on VxWorks access points and bridges, and access points based on Cisco IOS Software.


Figure 10 Enabling QoS Advertisements on a VxWorks Access Point


Figure 11 Enabling QoS Advertisements on a Cisco IOS Software Access Point

4  Deploying EDCF on VxWorks Firmware Version 12.00T Release

This section discusses what mechanisms are available on VxWorks access points and bridges for applying traffic classification to particular traffic types. VxWorks is available with Cisco Aironet 1200, 350, and 340 Series Access Points and the Cisco Aironet 350 Series Wireless Bridge.

4.1  Appliance-Based Prioritization

The access point can prioritize traffic based upon a WLAN client identifying itself as a particular appliance that requires a particular traffic classification. Currently, Cisco access points support only VoIP appliances. These VoIP appliances use proprietary registration messages to identify themselves. The best example of this process is the negotiation that occurs between the access point and a Symbol VoIP WLAN handset. A protocol defined by Symbol allows the handset to be identified, and provides downstream traffic to these handsets with an interactive voice classification.

4.2  VLAN-Based Prioritization

Figure 12 shows that the default priority of a VLAN can be set. This priority is applied to all traffic, unless the priority is overridden by a filter setting. This filter setting is applied via the policy group on the VLAN.


Figure 12 VLAN Priority Setting

4.3  Policy Group-Based Prioritization

For Cisco Aironet software based on earlier VxWorks software (prior to firmware release 12.00T), the access point filters allow the classification of traffic based upon Ethertype, IP protocol, or IP port. These classifications grouped as "Policy Group" (set of Layer 2, 3, and 4 filters) are applied to EDCF in VxWorks firmware release12.00T. Figure 13 shows an example of a filter classifying traffic.


Figure 13 QoS Classification Using a Filter

The access point also has a default filter to classify all SpectraLink voice traffic with voice priority. The user does not have to enable this filter (Figure 14). However, the user does have the choice of modifying and applying this filter (as part of a policy group) to a specific VLAN or an interface (Figures 15 and 16).


Figure 14 SpectraLink Filter Configuration


Figure 15 An Example Policy Group

(Default VoIP Policy Group with the SpectraLink Filter)


Figure 16 Applying a Policy Group to a VLAN for QoS Classification

4.4  CoS Value-Based Prioritization

Traffic that comes to the access point over an Ethernet trunk, if already classified by its CoS settings within IEEE 802.1D, will have that classification mapped to EDCF and applied unless the subsequent traffic classification is applied by one or more of the classification methods.

4.5  DSCP Value-Based Prioritization

The DSCP values in the IP packets may be used to classify the traffic based upon the DSCP to CoS mappings shown in Figure 17.


Figure 17 DSCP to CoS Mapping

4.6  Combining QoS Setting Requirements

The EDCF settings shown in Figure 10 are applied by the radio, and are determined by the classification that is applied at the radio. Network engineers must be aware of where the traffic classification is applied in order to plan and design the QoS settings appropriately. The first classification that occurs is the one that is selected and used.

  • If the frame arrives at the access point with a CoS setting via IEEE 802.1p, this what is used.
  • If a station has identified itself as a particular CoS, this is what is used (per-appliance QoS, an example would be a Symbol VoIP device).
  • If a policy group (set of Layer 2, 3, and 4 filters) is defined per-VLAN or interface, CoS defined by the policy group is assigned to the specified traffic flow (example: SpectraLink VoIP device).
  • If DSCP is marked within the IP packet, this is converted to appropriate CoS as defined by the DSCP-to-CoS mapping table on the access point (as shown in Figure 17).
  • If none of the above mechanisms are viable, the default CoS setting for the VLAN is used for all traffic.

Figure 18 illustrates the QoS classification precedence described in the above list:


Figure 18 QoS Classification Precedence on VxWorks-Based Access Points and Bridges

The flow of traffic shown in Figure 18 moves from the Ethernet interface to the radio interface, but the same classification principles apply in the opposite direction. For example, frames from a station classified with a particular CoS will retain that CoS within the access point, despite any other classification settings.

5  Deploying EDCF on Cisco IOS Software based Access Points

This section discusses the mechanisms available on the Cisco Aironet 1100 Series Access Point for applying traffic classification to particular traffic. The Aironet 1100 Series, based on Cisco IOS Software, has significant QoS operational differences as compared to the VxWorks-based Cisco Aironet 1200, 350, and 340 Series Access Points. However, because it is based on Cisco IOS Software, the Aironet 1100 Series is consistent with current Cisco IOS Software implements, and users familiar with configuring Cisco switch and router QoS settings should find the commands and configuration for this product familiar.

5.1  Appliance-Based Prioritization

The access point based on Cisco IOS Software can prioritize traffic based upon a WLAN client's request for a particular traffic classification because of its appliance type. Currently, Cisco access points support only VoIP appliances. These VoIP appliances use proprietary registration messages to identify themselves. The best example of this process is the negotiation that occurs between the access point and a Symbol VoIP WLAN handset. A protocol defined by Symbol allows the handset to be identified, and provides downstream traffic to these handsets with an interactive voice classification.

The VxWorks-based access point allows a per-station classification of traffic that permits these handsets to identify themselves and automatically classify traffic. The access point based on Cisco IOS Software supports the registration of the handsets to the access point through the global command line interface (CLI) command: dot11 phone.

This can also be configured via the graphical user interface (GUI) as illustrated in Figure 11.

5.2  CoS Value-Based Prioritization

Traffic that arrives at the access point over an Ethernet trunk, if already classified by its CoS settings within IEEE 802.1D, will have that classification mapped to EDCF and applied unless the Per-Appliance classification applies a subsequent classification.

5.3  Class-Map-Based Prioritization

Traffic flows are identified by IP TOS, DSCP, or protocol settings with class-map-based prioritization. An identified downstream traffic flow is given a specific CoS applied over the radio interface. This process is consistent with current Cisco IOS Software implementations.

Figure 19 illustrates an example setting of a class-map-based QoS policy via the Cisco Aironet 1100 Series Access Point Web interface. The policy name is example. Example creates classification rules based upon IP precedence, DSCP values, and an IP protocol. These classification rules are then applied on the radio interface.


Note:    The IP protocol 119 setting provides ongoing support on the access point for SpectraLink IEEE 802.11 handsets.



Figure 19 Class-Map-Based QoS Policy Example

After applying the class-map-based QoS policy, the changes are reflected in the access point CLI (Figure 20).


Figure 20 Cisco Aironet 1100 Series Access Point CLI
class-map match-all _class_example2
match ip protocol 119
class-map match-all _class_example0
match ip precedence 2
class-map match-all _class_example1
match ip dscp 46
 
policy-map example
class _class_example0
set cos 5
class _class_example1
set cos 5
class _class_example2
set cos 0
class class-default
set cos 0
 
interface Dot11Radio0.825
 
service-policy output example
 

5.4  VLAN-Based Prioritization

Figure 21 illustrates the default priority (CoS) set using a class-map definition on an access point based on Cisco IOS Software. This class-map is applied to an interface or a VLAN and the specified priority is applied to all traffic, unless the priority is overridden by one of the mechanisms described above (per station, 802.1p, 802.1D CoS, class-map-based IP TOS or DSCP).


Figure 21 Default CoS Setting Using a Class-Map

5.5  Combining QoS Setting Requirements

The EDCF settings are applied by the radio and are determined by the classification applied at the radio. Network engineers must be aware of where the traffic classification is applied in order to plan and design the QoS settings appropriately. The first classification that occurs is the one that is selected and used.

  • If a station has identified itself as a particular CoS, this is what is used (per-appliance QoS, an example would be a Symbol VoIP device).
  • If the frame arrives at the access point with a CoS setting via IEEE 802.1p or 802.1D, this is what is used.
  • If a class-map-based classification (IP TOS, IP DSCP, IP protocol, or default CoS) is defined per VLAN or interface, CoS defined by the class-map-based QoS policy is assigned to the specified traffic flow (example: SpectraLink VoIP device).
  • If none of the above mechanisms are viable, the default CoS setting for the VLAN is used for all traffic.

Figure 22 illustrates the QoS classification precedence on access points based on Cisco IOS Software, as described in the above list.


Figure 22 QoS Classification Precedence

5.6  Additional QoS Features

The Cisco Aironet 1100 Series Access Point allows the setting of different CWmin and CWmax values depending upon the traffic classification, as shown in Figure 23.


Figure 23 Class to CWmin and CWmax Settings

In addition to the CWmin and CWmax values shown in Figure 23, a Fixed Slot Time setting is available. The Fixed Slot Time is referred to as the AIFS in the IEEE 802.11e Draft. The AIFS is a variable distributed coordination function (DCF) value. The standard DCF time equals two slots times. Traffic classifications with a slot time greater than two must wait the additional slot times before sending or beginning to decrement their random backoff counters, giving further precedence to traffic with low CWmin and DCF timing.

6  Guidelines for Deploying Wireless QoS

The same rules for deploying QoS in a wired network apply to deploying QoS in a wireless network. The first and most important guideline in QoS deployment is "know your traffic." Know your protocols, application's sensitivity to delay, and traffic bandwidth.

QoS does not create additional bandwidth; it simply gives more control of where the bandwidth is allocated.

Voice traffic is probably the most familiar QoS application. The following are examples of how the QoS for voice is applied to different applications. When using the traffic classification schemes in the access point, remember that once the classification is changed from a default station, the application of any further mechanisms will not further alter the classification.

6.1  IP SoftPhone and Other PC and PDA-Based VoIP Solutions

With IP SoftPhone and other PC and PDA-based VoIP solutions, the access point may not connect to the wired Ethernet via IEEE 802.1q. VLANs may not be configured. In this case, the frames from the wired network will not contain CoS information for the access point.

If the wired network is using IP type of service (ToS) or IP DSCP to mark traffic, these marks can be recognized by the access point through the access point's DSCP-to-CoS mapping feature, as shown in Figure 17 (VxWorks) or using class-map-based prioritization (Cisco IOS Software) as shown in Figure 19.

If VLANs are used, the access point can use the CoS settings within IEEE 802.1p, and the DSCP-to-CoS mapping is done by the upstream device. If the CoS settings of IEEE 802.1p are not used, the access point uses the DSCP settings. If switch infrastructure does not mark frames or packets with IEEE 802.1p CoS or IP TOS or DSCP, then the VLAN default CoS on the access point is used to apply a specific wireless CoS.

6.2  Symbol Handsets

If Symbol handsets are used in the WLAN, the Symbol Extensions should be enabled as shown in Figure 10 or 11.

6.3  SpectraLink Handsets

As discussed in sections 4.3 and 5.3, SpectraLink Voice Protocol is prioritized in the same manner as in the pre-WLAN QoS access point configuration because the access point has a default filter to classify all SpectraLink voice traffic with voice priority.

The difference between the previous access point prioritization is that it was limited to prioritizing within the queuing within the access point. With the QoS enhancements, that traffic will be prioritized over the radio interface.

Figure 24 illustrates the SpectraLink Voice Protocol architecture for VxWorks Firmware Release 12.00T and Cisco IOS Software 12.2(4)JA QoS features:


Figure 24 SpectraLink VoIP Deployment

6.4  Leveraging Existing Network QoS Settings

Support for IEEE 802.1p and DSCP allows the access point to leverage the existing QoS classification and prioritization in the wired network. For more information on the design and configuration of QoS for a Cisco AVVID (Architecture for Voice, Video and Integrated Data) network, refer to: "Cisco AVVID network Infrastructure Enterprise Quality of Service Design" at http://www.cisco.com/application/pdf/en/us/guest/netsol/ns17/c649/ ccmigration_09186a00800d67ed.pdf


1Figures quoted are for 802.11b; not 802.11a

2No known vendor claims to support PCF

3No acknowledgements are shown, no fragmentation occurs.