I want to take this opportunity to compare the obvious comparison of Apple’s antenna issue with the iPhone4 with a typical WiFi client analogy.

Apple released the iPhone 4 this week. There are early reports of antenna issues. Apparently the antenna design is flawed. Depending on how you hold the phone it could attenuate the signal. Steve Job’s  responded to emails , “just don’t hold it like that.” Way to go Jobs! This reminds me of the old analogy “A man goes to the doctor and says, Doc when I do this it really hurts. The Doc responds then don’t do that”.

Here is a classic example of a client issue. Customers reported issues almost immediately with cell reception with the new iPhone4. So what gives!? … They didn’t change the cell towers over night (access points)! Their phones changed (clients)!

If you read the reports they are using terms you as wireless engineer should be very familiar with, “attenuation, signal degradation, poor reception”. These are general terms we hear or use ourselves. Wireless is a 2-way communication. Often non wireless educated folks assume when there are issues it is the network and by this I mean the wireless access point or wireless infrastructure. They often don’t consider the wireless client.

I can think back to 2003’ish (or there around) when Intel released the Intel 2200b/g clients. This was around the time Cisco purchased Airespace. If you were in WiFi you surly remember this issue.

For those of you who weren’t, here is a quick recap. The Intel 2200 clients were flawed and were flawed for well over 2 months before Intel released a driver fix. The 2200 driver had big issues! When authenticated and in OFDM rates, Intel 2200 clients would not rate shift down to DSSS. As clients moved away from the access point the rate shifting stopped and the client would drop off the wireless. Of course back then customers always looked at the network. “Its got to be the AP”.  Especially the early adopters of the new Cisco/Airespace solution. Immediately people pointed blame at Cisco thinking there was an issue with the new controller solution they purchased from Airespace, which wasn’t the case.

Rumor has it Cisco did an assist with Intel with the replacement driver.

Fast forward to today…

WiFi engineers have more tools, training and hands on experience to quickly troubleshoot these issues. In fact, a good wireless engineer can determine if it’s a potential client issue with a quick wireless client capture and debug at the controller or AP. Manufactures of Wireless clients have also improved, especially Intel since they work closely with Cisco. You will find troubleshooting and diagnostics tools on the client side more today then ever before.

You have to remember wireless clients aren’t created equal. They all hear differently  (receive sensitivity) and have different transmit power levels and they all have their own operating behavior (when to roam, how they interpret signal strength, etc). Lets face it, some wireless clients are just crap.

Conclusion

If you are new to WiFi. Wireless clients have an equal part in the communication efforts and should be factored in when troubleshooting. In the case of the iPhone4 issue. The didn’t move the cell towers over night. The client changed!

Did you know Cisco and Intel have a joint program called E2E which enhances roaming !? Its called E2E, End-2-End.

Enhanced neighbor list request (E2E)—The End-2-End (E2E) specification is a Cisco and Intel joint program that defines new protocols and interfaces to improve the overall voice and roaming experience. It applies only to Intel clients in a Cisco Compatible Extensions environment. Specifically, it enables Intel clients to request a neighbor list at will. When this occurs, the AP forwards the request to the WLC. The WLC receives the request and replies with the current Cisco Compatible Extensions roaming sublist of neighbors for the AP to which the client is associated.

 You can also view this in the gui. 

WIRLESS-->CLIENTS-->DETAIL

Something you need to know if you plan to take any level of Cisco wireless certifications and more importantly in the field is the status LEDs on the Cisco Wireless CB21.

Easy way to remember:

Alternate blinking; think of SCANNING back and forth looking for a network

Both LEDs blinking slowly; means connected. Think of a pulse 

Both LEDs blinking fast; transfer data

The 2 other status LEDs you need to worry about are the POWER SAVE indications. Only the GREEN indicator is used.  

It is important to understand the difference between active and passive client scanning. Here is an overview ~ Wireless clients learn about available APs by scanning other IEEE 802.11 channels for available APs on the same WLAN/SSID. Scanning other IEEE 802.11 channels can be performed actively or passively as follows: 

Active scan—Active scanning occurs when the client changes its IEEE 802.11 radio to the channel being scanned, broadcasts a probe request, and then waits to hear any probe responses (or periodic beacons) from APs on that channel (with a matching SSID). The IEEE 802.11 standards do not specify how long the client should wait, but 10 ms is a representative period. The probe request frames used in an active scan are one of two types:

Directed probe—The client sends a probe request with a specific destination SSID; only APs with a matching SSID will reply with a probe response 

Broadcast probe—The client sends a broadcast SSID (actually a null SSID) in the probe request; all APs receiving the probe-request will respond, with a probe-response for each SSID they support.

During a channel scan, the client is unable to transmit or receive client data traffic. There are a number of approaches clients take to minimize this impact to client data traffic:

•Background scanning—Clients may scan available channels before they need to roam. This allows them to build-up knowledge of the RF environment and available APs so they may roam faster if it becomes necessary. Impact to client traffic can be minimized by only scanning when the client is not actively transmitting data, or by periodically scanning only a single alternate channel at a time (scanning a single channel incurs minimal data loss)

•On-roam scanning—In contrast with background, on-roam scanning occurs after a roam has been determined necessary. Each vendor/device may implement its own algorithms to minimize the roam latency and the impact to data traffic. For example, some clients might only scan the non-overlapping channels.

Typical Scanning Behavior

Although most client roaming algorithms are proprietary, it is possible to generalize the typical behavior.

Typical wireless client roam behavior consists of the following activities:

•On-roam scanning—This ensures clients have the most up-to-date information at the time of the roam.

•Active scan—An active scan is preferred over a passive scan, due to lower latency when roaming.
There are some informational attributes that may be used to dynamically alter the roam algorithm:

•Client data type—For example, voice call in progress

•Background scan information—Obtained during routine periodic background scans

Ways in which attributes can be used to alter the scan algorithm include: •Scan a subset of channels—For example, information from the background scan can be used to determine which channels are being used by APs in the vicinity. •Terminate the scan early—For example, if a voice call is in progress, the first acceptable AP might be used instead of waiting to discover all APs on all channels. •Change scan timers—For example, if a voice call is in progress, the time spent waiting for probe responses might be shortened during an active scan.

A wireless connection is a two way street. All to often Admins will ONLY look at what the Client reports from the AP (how well it hears the AP - client radio receive sensitivity). But have you considered how well the AP hears your client ??

We call this "client to access point". For a better understanding, think back when you were a kid and your dad yelled at you for not taking out the trash the night before trash day. Your dad is very loud -- to get his point across and everyone in the house (or neighborhood) can hear him! Perhaps, you answer back to your dad with a low, soft," I’m sorry, I forgot"... Your dad heard your response as a whisper .

In this example your dad is the access point @ 100mW  power (loud) and you are the wireless client @ 5mW power (low). You as the wireless client heard your dad loud and clear, but your dad didn't hear you so well. 

When you check your wireless supplicant and it registers -75dB, this is how loud you hear the AP (or your Dad in my example) - Again this is "access point-to-client".

But you want to see how well the AP (or your Dad in my example) hears you,  "client to-access point". . With a Cisco WLC you can perform a LINKTEST. This can be done in the GUI, WCS or CLI. Here is the command in the CLI. 

(Cisco Controller) >linktest 00:02:10:11:02:68 <-- Wireless NIC MAC Address

The beauty of Cisco CCX is that when enabled on both the client and controller it will report back both access point-to-client and client to-access point readings. 

When CCX v4 is enabled on both the controller and the client being tested, information similar to the following appears: 

CCX Link Test to 00:02:10:11:02:68.

     Link Test Packets Sent...................................... 20

     Link Test Packets Received................................. 10

     Link Test Packets Lost (Total/AP to Client/Client to AP).... 10/5/5

     Link Test Packets round trip time (min/max/average)......... 5ms/20ms/15ms

     RSSI at AP (min/max/average)................................ -60dBm/-50dBm/-55dBm

     RSSI at Client (min/max/average)............................ -50dBm/-40dBm/-45dBm

     SNR at AP (min/max/average)................................. 40dB/30dB/35dB

     SNR at Client (min/max/average)............................. 40dB/30dB/35dB

     Transmit Retries at AP (Total/Maximum)...................... 5/3

     Transmit Retries at Client (Total/Maximum).................. 4/2

     Transmit rate:  1M   2M   5.5M   6M   9M  11M 12M 18M   24M   36M  48M  54M  108M

     Packet Count:   0     0     0    0    0    0   0   0     0     2    0   18     0

     Transmit rate:  1M   2M   5.5M   6M   9M  11M 12M 18M   24M   36M  48M  54M  108M

     Packet Count:   0     0     0    0    0    0   0   0     0     2    0    8     0

When CCX v4 is not enabled on either the controller or the client being tested, fewer details appear:

Ping Link Test to 00:02:10:11:02:68.

        Link Test Packets Sent.......................... 20

        Link Test Packets Received...................... 20

        Local Signal Strength........................... -58dBm

        Local Signal to Noise Ratio..................... 29dB

You can also config the default "linktest" settings:

(Cisco Controller) config>linktest ?
frame-size     Configures linktest frame-size for each packet.
number-of-frames Configures number of frames to send for linktest.

Again, another reason WHY a proper wireless site survey is needed and why you need to always consider your lowest common denominator (client) for wireless reliability. If your dad (AP) is always yelling and you (client) always whisper back you are bound to have COMMUNICATION problems. Vocera is one of these such applications.