Pages

Thursday, April 1, 2010

Determining AP Transmit Power

One feature of the Cisco UWN that causes a lot of confusion for people is accurately determining lightweight access point power levels.

In the autonomous world this is fairly cut and dry, you configure the power level on each radio using the "power local dBm" interface command, which is then adjusted downward if necessary based on the channel and regulatory domain configured on the access point. You can then verify the power level in use with the "show controllers Dot11Radio" command:

Configured CCK Power: 20 dBm
Configured OFDM Power: 20 dBm
Active power levels by rate
     1.0 to 11.0 , 20 dBm
     6.0 to 54.0 , 17 dBm, changed due to regulatory maximum
  OffChnl Power: 20, Rate 1.0
Allowed CCK Power Levels: -1 2 5 8 11 14 17 20
Allowed OFDM Power Levels: -1 2 5 8 11 14 17 20
Allowed Client Power Levels: 2 5 8 11 14 17 20


Here, you can see the configured power level is 20 dBm, and the active power level is 20 dBm for 802.11b data rates and 17 dBm for 802.11g data rates. Also notice the output states that the power level for 802.11g data rates has been automatically changed due to the regulatory maximum. This AP is deployed in the U.S. and follows the -A regulatory domain restrictions.

However, on the Cisco UWN things become a bit harder to interpret. This is mainly caused because the power level assignment is performed using numeric level representations, not by absolute dBm value. Whether the power level is assigned dynamically through TPC (part of RRM) or statically by the administrator, it is always represented with numeric values of 1 through 8 (1 being highest power, 8 being lowest). Each power level reduction roughly corresponds to a 3 dB decrease (50% absolute power decrease), but this does not always hold true.

How do you determine the actual power level in use by a lightweight AP?

First, let's view the supported power levels on the AP. We can do this through the CLI with the command "show ap config { 802.11a | 802.11b } ap_name"

Tx Power
  Num Of Supported Power Levels ............. 8


  Tx Power Level 1 .......................... 17 dBm
  Tx Power Level 2 .......................... 15 dBm
  Tx Power Level 3 .......................... 14 dBm
  Tx Power Level 4 .......................... 11 dBm
  Tx Power Level 5 .......................... 8 dBm
  Tx Power Level 6 .......................... 5 dBm
  Tx Power Level 7 .......................... 2 dBm
  Tx Power Level 8 .......................... -1 dBm
  Tx Power Configuration .................... AUTOMATIC
  Current Tx Power Level .................... 2


Phy OFDM parameters
  Configuration ............................. AUTOMATIC
  Current Channel ........................... 36

This is a 1242 AP, and we can see the supported power levels are from 17 dBm down to -1 dBm, mapping to corresponding power levels 1 through 8, as expected. With this information, an administrator might expect the AP to transmit at 15 dBm when set to a power level of 2. This would be wrong!

Here's why. The supported power levels do not take into account other variables affecting tranmit power limits, such as current channel assignment and regulatory domain restrictions. This means that the power level values (1-8) will vary based on the maximum level allowed in the regulatory domain for the current operating channel. Therefore, any given power level value will not always equate to the same absolute power level in dBm across APs on different channels. Talk about making an administrator's life more difficult! This is more of a concern in the 5 GHz bands than the 2.4 GHz band, due the different intended purposes for various spectrum blocks in 5 GHz (outdoor vs. indoor, DFS requirements, etc.).

Continuing the example, the same command above also lists the current channel as 36. The FCC regulatory maximum transmit power for this channel is 11 dBm. This information can be found in the Cisco document "Channels and Maximum Power Settings for Cisco Aironet Lightweight Access Points, OL-11321-07". So, power level 1 will correspond to 11 dBm when using channel 36 in the U.S., power level 2 to 8 dBm, and so on down the list. (Note, that if only 5 power levels are supported, anything lower than power level 5 configured on the AP will apply the lowest power level supported)

How can we verify this information? We can see the adjusted active power level of the AP using a few CLI commands:

debug ap enable ap_name
debug ap command "show controller Dot11Radio1" ap_name

(Cisco Controller) debug ap enable ccielwap
(Cisco Controller) debug ap command "show controller d1" ccielwap

Mon Feb 22 08:19:34 2010: ccielwap: interface Dot11Radio1

Mon Feb 22 08:19:34 2010: ccielwap: Carrier Set: Americas (OFDM) (US) (-A)
Mon Feb 22 08:19:34 2010: ccielwap: Uniform Spreading Required: Yes
Mon Feb 22 08:19:34 2010: ccielwap: Configured Frequency: 5180 MHz Channel 36

Mon Feb 22 08:19:34 2010: ccielwap: Configured Power: 8 dBm
Mon Feb 22 08:19:34 2010: ccielwap: Active power levels by rate
Mon Feb 22 08:19:34 2010: ccielwap:      6.0 to 54.0 , 8 dBm
Mon Feb 22 08:19:34 2010: ccielwap:   OffChnl Power: 11, Rate 6.0
Mon Feb 22 08:19:34 2010: ccielwap: Allowed Power Levels: -1 2 5 8 11


Wow! How's that for complex. The easiest way that I have found to deal with this is to know your environment and your design principles. If you typically use a certain channel pattern layout or have limited the available channels in the DCA configuration, know the corresponding maximum power levels allowed for each channel. Perhaps make a quick cheat-sheet for reference. Many channels will be the same, but the few that are different will be important to remember.

Do you know of any other tips or tricks for determining power levels?

Andrew

3 comments:

  1. Any thoughts on how to locate this in a Wireshark capture?

    ReplyDelete
    Replies
    1. You might be able to see it in a Cisco proprietary information element if DTPC is enabled in the 802.11 Network Settings. DTPC enables CCX clients to learn the current power level of the AP so they can adjust their power to match. Most protocol analyzers won't be able to properly decode those IEs however, since they are Cisco proprietary. You would have to reverse engineer the Cisco vendor-specific IEs to figure out which one is for DTPC, and then figure out the different fields in the IE and which one is the current AP power level.

      My best guess is that this MAY be in IE #0x96 (150) with fields:
      ID - 96
      Length - 2 bytes?
      Vendor OUI - 004096
      Type - 00
      Current Power Level - 1 byte?
      Unknown field

      I don't have a Cisco capture that I can reference at this time, but check that out and let me know if you can figure out the power level. I'd like to hear if you're successful.

      Andrew

      Delete
  2. Thanks Revolution! This is what I gathered from the IEEE 802.11 wireless LAN management frame and how I used it to verify the AP's power level (PL) which does not match the WLC or AP's CLI.

    -Tagged paramters
    -Tag: Cisco Unknown 96: Tag 150 Len 6
    -Tag number: Cisco Unknown 96 (150)
    -Tag length: 6
    -Tag interpretation: Not interpreted
    00 40 96 00 1c 00

    The WLC and AP shows the AP power level at 5 (the lowest). This indicates the PL to be at PL 1 (the highest @ 28 dBm or 1c). I changed the PL to 1 in the gui, verified it in the CLI on the AP and WLC and returned it to PL5 and captured from Wireshark again with my monitor AP in sniffer mode. Very handy feature with the 3502s.

    Analyzing the two captures, I am now seeing PL 5 on the AP/WLC and the Wireshark trace. The hex is now 40 96 00 10 00 (the ten indicating 16 dBm converting from HEX to DEC). The PLs for a Cisco 1522 in MESH mode for both 802.11 a and b/g:

    PL1 = 28 dBm = 1c
    PL2 = 25 dBm = 19
    PL3 = 22 dBm = 16
    PL4 = 19 dBm = 13
    PL5 = 16 dBm = 10

    Rule of thumb folks, do not trust your WLC or APs CLI if your clients are indicating problems with roaming and connectivity and things just don't add up. Using a wireless sniffer and protocol analyzer is a good tool to have in your toolbox.

    ReplyDelete