Troubleshooting Call Admissions Control

VoWLAN Call Capacity

An important factor to consider in a Voice Over Wireless LAN (VoWLAN) is Call Capacity Planning. The number of simultaneous VoWLAN calls that can be supported on a given AP and channel is very important to understand. This value can vary depending upon the static parameters configured on the Wireless LAN Controller or IP Phone or the variations within the RF environment.

For example, the VoWLAN maximum capacity for a Cisco Unified IP Phone 792xG using the Cisco Unified Wireless Network with Load-Based CAC is expected to allow a greater number of calls than with Static CAC in an environment that has ideal RF characteristics. For example, you may get 14 VoWLAN calls per 2.4 GHz channel and 20 simultaneous VoWLAN calls per 5 GHz channel. These capacity values are based on assuming no competing high priority WLAN traffic and normal background noise that adhere to the appropriate best practice recommendations as outlined in the section of RF Design Validation.

Note Because the 5 GHz spectrum generally features less noise and interference, there can be greater capacity with the higher carrier frequency implementation. The additional non-overlapping channels available in the 5 GHz spectrum also provides a great deal more call capacity for a given area.

TSPEC Admissions Control

Traffic Specification (TSpec) allows an 802.11e client to signal its traffic requirements to the AP. In the 802.11e MAC definition, two mechanisms provide prioritized access. These are the contention-based EDCF option and the controlled access option provided by the transmit opportunity (TXOP). When describing TSPEC features where a client can specify its traffic characteristics, it is easy to assume that this would automatically result in the use of the controlled access mechanism, and have the client granted a specific TXOP to match the TSPEC request. However, this does not have to be the case; a TSpec request can be used to control the use of the various ACs in EDCF. Before a client can send traffic of a certain priority type, it must have requested to do so via the TSpec mechanism. For example, a WLAN client device wanting to use the voice AC must first make a request for use of that AC. Whether or not AC use is controlled by TSpec requests is configurable with voice and video ACs controlled by TSpec requests, and best-effort and background ACs can be open for use without a TSpec request. The use of EDCF ACs, rather than the 802.11e Hybrid Coordinated Channel Access (HCCA), to meet TSpec requests is possible in many cases because the traffic parameters are sufficiently simple to allow them to be met by allocating capacity, rather than creating a specific TXOP to meet the application requirements.

Add Traffic Stream

The Add Traffic Stream (ADDTS) function is how a WLAN client performs an admissions request to an AP. The 792x client signals its TSPEC admission request to the AP in one of two forms:

ADDTS Action Frame-this occurs when a phone call is originated or terminated by the 792x client associated to the AP. The ADDTS contains TSpec and might contain a traffic stream rate set (TSRS) IE (Cisco Compatible Extensions v4 clients).

Association and re-association message

The association message might contain one or more TSpecs and one TSRS IE if the STA wants to establish the traffic stream as part of the association. The re-association message might contain one or more TSPECs and one TSRS IE if an STA roams to another AP.

The ADDTS contains the TSpec element that describes the traffic request. See Figure 5-1 and Figure 5-2 for examples of an ADDTS request and response between a Cisco Unified Wireless IP Phone 792xG WLAN handset and a Cisco AP. Apart from key data describing the traffic requirements, such as data rates and frame sizes, the TSpec element also tells the AP the minimum physical rate that the client device will use. This allows the calculation of how much time that station can potentially consume in sending and receiving in this TSpec, and therefore allowing the AP to calculate whether it has the resources to meet the TSpec. TSpec admission control is used by the WLAN client (target clients are VoIP handsets) when a call is initiated and during a roam request. During a roam, the TSpec request is appended to the re-association request.

Figure 5-1 ADDTS Request Decode

Figure 5-2 ADDTS Response Decode

Understanding Static CAC

As mentioned previously, there are two types of Admissions Control. Static CAC is based on a percentage of the total Medium Times available and is measure in increments of 32 microseconds. In this section, we will cover how to configure Static and Load-Based CAC and also how to debug it.

Please see Figure 5-3 and Figure 5-4 for an example using default parameters.

Figure 5-3 Static CAC Configuration Example

Figure 5-4 Load-Based CAC Configuration Example

In an effort to understand how Static CAC works with regard to allocating bandwidth, you need to understand the basics with regard to the math. In circumstances where the 792xG Series wireless IP phone uses a G.711 codec and the Cisco Wireless LAN Controller is configured to utilize data rates are in accordance with Cisco VoWLAN best practices, a single uni-directional RTP stream will utilize 538 Medium Times, or 1076 Medium Times per call.

An AP supports a total of 31,250 Medium Times, which is defined in the 802.11e standard and is an RF measurement used by TSPec for Admissions Control. In a Static CAC configuration, the Medium Times are multiplied times the Max RF bandwidth and Reserved Roaming Bandwidth and divided by the number of calls that are made against a single Access Point during Association.

For example, if Static CAC has been configured using default settings, codecs and data rates in accordance with VoWLAN Design and Deployment Best practices, the formula to calculate the total number of calls is as follows:

If each uni-directional RTP stream utilizes 538 Medium Times, you would multiply that times 2 to determine to the total MT's per call. In this example, it is 1076 MTs per call.

–31250 (Medium Times) * Configured Max RF Bandwidth \ 100 = (maxBw)

–(maxBw) * Configured Reserved Roaming Bandwidth \ 100 = (roamBw)

–The (roamBw) should then be subtracted from the (maxBw), and then divided by 1076 yielding the total number of calls allowed on the VoWLAN.

Note By default the Max RF Bandwidth is 75% and Reserved Roaming Bandwidth is 6%.

Debugging Static CAC

Scenario:

In this scenario, the Static CAC configuration is as follows:

•Max RF Bandwidth: 40%

•Reserved Roaming Bandwidth: 6%

Using the Formula outlined above, we can conclude the following:

•31250 (Medium Times) * 40% \ 100 = 12500 (maxBw)

•12500 (maxBw) * 6% \ 100 = 750 (roamBw)

•12500 (maxBw) - 750 (roamBw) = 11750 (avail_Bw) \ 1076 (bw_req) = 10.92 calls.

From the example, we can see that based on a Max RF Bandwidth of 40% and Reserved Roaming Bandwidth of 6%, the VoWLAN will yield 10 calls with the 11th call being denied access to the WLAN. Please refer to Figure 5-5 through Figure 5-9, which outline how Static CAC can be debugged.

Figure 5-5 Debugging Static CAC Example (part 1)

Figure 5-6 Debugging Static CAC Example (part 2)

Figure 5-7 Debugging Static CAC Example (part 3)

For the purposes of this troubleshooting guide the length of the debug was reduced, however, when issuing the "debug cac all enable" command on the Cisco Wireless LAN Controller, you will noticed that as additional calls are made one after another on the same AP, the available bandwidth (Medium Times) decrements by 1076 per call until the Medium Times (availBw) are exhausted. Once exhausted, the AP will send the following error seen in the output below. The will result in a "Network Busy" message on the 792xG Series wireless IP phone.

Figure 5-8 Debugging Static CAC Example (part 4)

As you can see below, the bandwidth required is 1076 (bw_req = 1076) and the Maximum Bandwidth is 12500 (maxBw = 12500) Since the bandwidth allocated has reached 10760 (bwAloc = 10760), that leaves 1740 Medium Times, of which 750 (roamBw = 750) has been allocated to Reserved Roaming Bandwidth, resulting in 990 Medium Times remaining. Finally, this results in insufficient bandwidth and thus causes the following output to be seen in the "debug cac all enable" on the Cisco Wireless LAN Controller.

Figure 5-9 Debugging Static CAC Example (part 5)

Debugging LBCAC

Load-Based CAC on the other hand is significantly more difficult to debug. LBCAC is dynamic with regard to the algorithm used to decrement Medium Times from the total that is available. LBCAC takes into consideration different metrics, such as load, Co-channel interference, SNR, etc. and will therefore yield different results when tested. From our experience, it is very difficult to yield consistent results as RF fluctuates and changes within the given environment. Results tend to vary from one cell area to another and even in cell areas that yield the same signal strength.

At Cisco, we have seen consistent results with regard to LBCAC tests performed in a shield room, however, those results are only an indication to us of how the 792xG Series wireless IP phone might perform under the most ideal circumstances. In the real world, results will vary significantly. It's important to understand that RF is dynamic in nature and while a single AP might allow 15 calls on Tuesday, it may yield more or less the next day as environmental circumstances change. Overall, LBCAC does yield a greater number of calls per AP due to the mechanisms it uses to decrement the available Medium Times. Remember, with Static CAC, a bi-directional RTP stream decrements a fixed value of 1076 MT's from the available bandwidth, while LBCAC will factor in other variables and might only decrement 700 or 800 medium times per call. The only way to conclusively determine why results in LBCAC changes so dramatically in a single area is to take wireless sniffer traces and perform Spectrum Analysis within a given environment and utilize that data to isolate root cause. If call capacity is of vital concern and your WLAN is not yielding the expected results, it's ideal to ensure that your VoWLAN deployment adheres to all of the outlined VoWLAN Design and Deployment Best practices and each phone sees at least 3 Access Points with an acceptable RSSI.

Chapter Summary

It's important to understand that the purpose of TSpec admission control is not to deny clients access to the WLAN; it's to protect the existing VoWLAN calls and to ensure that quality does no degrade. Without the implementation of CAC, any additional calls above and beyond the available bandwidth available will causes on overall degradation of quality to all VoWLAN users.net.