A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Tuesday, February 22, 2011

Autonomous Call Admission Control, admit-traffic?

On the autonomous APs, you can configure Call Admission Control (almost) like on the WLC. This feature allows you to decide how much bandwidth is allocated to Voice traffic on your radio.
But there are 2 places where you can set CAC (thus this article): in the QoS page and at the SSID level... so what is the difference?
To get what is going, a bit of background. You can setup Call Admission control in Services > QoS > 802.11b/g (or 802.11) Access Categories, by the bottom of the page:

This configuration adds the following line to the radio configuration:
dot11 qos class voice local
   admit-traffic narrowband max-channel 75 roam-channel 6

The result is that admission control is set on this radio. Voice can use up to 75% of the available bandwidth (based only on the AP dot11 traffic. To also use the noise and other APs activity, you need to get a controller and use Load based CAC). From these 75%, 6% are kept for roaming users (so that users roaming from other APs do not get disconnected when jumping to this AP).
This configuration applies to the radio, not to an SSID in particular. So any traffic matching voice classification (802.11e UP 6 and 7) on this radio for all SSIDs will be seen and controlled.
As this refers to 802.11e UP, the underlying expectation is that WMM is enabled on that radio. WMM is enabled by default, but could be disabled from Services > QoS > Advanced, for 802.11b/g or 802.11a. On the CLI, WMM is disabled with the radio command:
no dot11 qos mode

If you disable WMM, then the AP does not care anymore about the QoS field in the clients frames, and although WMM clients could still internally prioritize voice packets, the AP would not apply any admission control of any kind anymore.

Okay, but what if you do not set Call Admission Control? Could that be a problem? Well, yes. Many phones (and in particular the 7921) send TSPEC (traffic specification) information in a ADDTS QoS frame when roaming. If this is Greek to you, let's translate by saying that the phone tells the AP to which it is roaming that it wants to use a certain class of service. If CAC is not set, the AP does not really care about the type of traffic the client wants to send (as it is not going to filter the clients based on what type of traffic they send). The result is that, in the early days of this WMM adventure (in 2009!), the AP was responding to the phone reassociation request with a reassociation response that was not containing the CCKM information element, informing the phone about how fast roaming was handled (remember my default 6% bandwith left for roaming users? That's what we are talking about, the phone needs to know if there is space left on this new AP or not). Without this CCKM IE, the phone was lost and was hanging there, wondering what to do (wondering in fact if any other, better AP would be in range), before finally joining the AP anyway. This created a gap in conversations of about 1 to 1.5 seconds.
To go around this issue, you could then configure the SSID itself to say: "even though I do not set any specific call admission control or limitation on how much bandwidth can be used by this or that type of traffic, I do welcome VoIP traffic and BTW I do CCKM". This message was sent by setting the admit-traffic command under the SSID:
dot11 ssid XYZ

On the Web interface, this is done at the bottom of the SSID page:

In other words, the admit-traffic SSID command allows you to improve your CCKM clients roaming performances, without the need to limit the bandwidth allocated to voice users (local voice users or roaming voice users).
Now, what if you do have CAC enabled?... do you still need to set admit-traffic under the SSID? The answer depends on the IOS code and the associated AP hardware. The short answer is: if the admit-traffic (Call Admission Control) command is available under the SSID, always set it. Otherwise, you may have CAC set at the radio level, but the SSID blocking the TSPEC SCCP messages, in other words not answering with the CCKM IE anyway.

In a pure lab mindset, the prerequisite is that your AP runs a code where this feature is possible. The second requirement is that roaming is involved. If there is no roaming, you may want to set CAC to limit the VoIP bandwidth consumption, or you may not care about CAC. In all cases, a 1 to 1.5 second initial delay does not mater. It is an issue only when roaming is involved. So... read your lab scenario carefully.

Last tip: the default rate for TSPEC on the 7921/7925 is 12 Mbps, which should be enabled on the AP.  Make sure that 12 Mbps is always allowed on the radio that those phones use, otherwise your will be missing those messages, and you would be back to the voice gap issue.


  1. Hi Henry,
    Thanks for writing such a good document.I would like to know if ADDTS frame is sent regularly by the STA for each Voice/Video packet?is this packet(ADDTS) sent separately after an association request packet is sent. OR I am not sure if association request packet needs to be modified based on ACM bit set by AP if so what additional parameters gets added ans what default TSPEC values go in.Would you please let me know of more details.

  2. Hey Vinod,
    The ADDTS is sent at the beginning of the transmission, so it is not for each packet, it is for the entire stream. At the end of each service period (this is the AP defining the service period, which is a chunk of time during which the ADDTS is valid), the station can renew its ADDTS, or terminate it any time.
    You are right to mention that in most cases, phones doing ADDTS/Tspec disassociate, then reassociate, but this is to clean up the connection. The ADDTS request is an action frame, so the station needs to be first associated in order to be allowed to send it. What the ACM bit does is to tell stations that, once associated, they cannot start sending before requesting service from the AP through and ADDTS request bearing TSPEC information.
    hth :-)

  3. Hi Jerome - thanks for the comparison of QoS CAC and SSID CAC - it is really helpful.

    We would like to use SSID CAC, but neither the web UI option or the CLI command is available in our autonomous AP (12.4.25d-JA2). We confirmed WMM is enabled and CCKM is enabled for our SSID (using EAP-LEAP). Any ideas?



  4. Hi Dennis,

    Yes, you are right, this option disappears in the later codes. The logic is that this option affects the radio queuing. Si it makes sense to enable it at the radio level, but enabling it at the SSID was an inheritance from previous codes (where you would configure SSIDs from the radio sub-menu, so you would have under the SSID level items that were relevant to the radio itself). As long as you enable CAC at the radio level, it is also there at the SSID level (on that radio). Then, at the SSID level, if you set a key management mechanism that includes CCKM, the CCKM part is taken care of (regardless of the radio CAC settings)... in a sense, it is a simpler config than the older code, for the same result...

  5. I certainly appreciate your stuff provided in the blogs.