Tuesday, July 27, 2010

Beamforming, ClientLink, and Disappointing Test Results

With Cisco's release of 802.11n access points, they began touting a package a features marketed as M-Drive. Among those was a feature called ClientLink. As implied, this feature's goal is to improve wireless links for clients :)

ClientLink is an implementation of an optional feature in the 802.11n amendment known as Transmit Beamforming. There are various forms of beamforming, some standards-based, most proprietary to certain vendors. For an overview of different beamforming types, see these articles from Ruckus and Aerohive.

I like to think of these beamforming types as 3 distinct categories:

  1. Static Beamforming - think semi-directional or directional antennas. They don't change, or move, or dynamically adjust. They simply focus the signal in a specific direction. Signal gains can potentially be very large (>10dB), based on the dBi rating of the antenna selected.

  2. On-Chip Beamforming - this is 802.11n standards-based transmit beamforming. The radio chipset coordinates the signal processing across multiple transmit radio chains, altering timing and phase alignment of each signal, in an attempt to have multiple signal copies arrive at the receiver "in-phase" to provide passive gain. Signal gains are 3dB maximum, which is quite logical if you think about what's going on at the receiver - two in-phase signals merge, potentially doubling the amplitude of the signal at the receiver.

  3. Antenna Beamforming - this is what Ruckus does best. They have multiple antenna elements (an antenna array if you will), some polarized horizontally and some vertically. The radio chipset sends one signal and a complex formula selects the best possible antenna element combinations to transmit the signal to the client. Signal gains max out around 9dB in the Ruckus implementation, but I suspect it could be higher with different antenna array designs.

ClientLink would fit into the category of "on-chip beamforming"  using standards-based transmit beamforming with implicit feedback, since the client is not required to support beamforming and explicit feedback mechanisms. That's one of their big selling points, improvement of legacy clients by upgrading to 802.11n APs.

Test Setup
I recently had a chance to evaluate ClientLink performance (having done similar testing with Ruckus in the past). My testing consisted of a Dell Latitude D620 laptop with an integrated Dell Wireless 1490 802.11a/g adapter based on a Broadcom chipset, running the Juniper Odyssey supplicant. It is important to use an 802.11a or 802.11g adapter, as ClientLink only works with legacy devices since it uses both transmit radio chains to send the same signal to the client (spatial multiplexing for two-stream 802.11n data rates would use both radio chains, leaving none left for beamforming).

Cisco's documentation states that a maximum of 15 clients per radio can be supported using ClientLink at the same time. Any additional clients can connect, but won't get beamforming. Additionally, beamforming is supposed to kick into gear once a client's signal strength drops below a threshold (there's no point in attempting to improve SNR if the client already has a great signal). Those thresholds are -50 dBm or weaker for 802.11g, and -60 dBm or weaker for 802.11a.

Testing was performed in two locations. Location 1 is a production environment in a large multi-story downtown office building, with competing wireless networks and a large amount of client traffic. Location 2 is an isolated lab environment with no competing wireless networks, no clients, and no interference present in the environment. In each location, metrics were measured at increasing distances from the AP, including signal strength in dBm, data rate chose by the client, and iperf throughput to a gigabit wired host. Three iperf throughput tests were run at each distance and the average was taken.

All testing was performed on Cisco's latest code version with 3502 access points.

Test Results
Location 1 (Production Environment):

Location 2 (Lab):

Overall, I found ClientLink to be highly inconsistent. It actually appears to have hurt client performance in most situations. In the production environment, client performance was significantly worse in 5 out of the 6 locations when ClientLink was enabled. The lab environment faired somewhat better, but performance was still worse half of the time when ClientLink was enabled. High variations in performance like these will lead to very hard-to-diagnose issues in a real-world scenario.

This is the double-edged sword of monkeying with multiple copies of the same signal. If you get it right and phase alignment occurs at the receiver, performance improves. By that same token, if you get it wrong and the signals are out of phase, then you've hurt performance for the client.

Ultimately, I cannot recommend that Cisco customers use ClientLink as it stands today. I have to conclude that Cisco's current implementation will result in inconsistent network performance, an increase in network support incidents, and overall a less stable network connection for users.

Perhaps they'll fix these performance issues in a future release.



  1. I have been wanting to do a similar test. I have the Ruckus APs. It would be really nice to do a comparison similar to this:


    The beamforming in the ruckus seems to work fantastic for me.

  2. I wonder how Ruckus does with large numbers of clients, the algorythm must break down at some point and I suspect it starts with the clients farthest away. If you have a few clients to deal with it wouldn't appear to be an issue, but with lots of clients which is becoming the norm - the results could mean big issues, more money, more time adding gear, etc, etc...

  3. We use the Xirrus Arrays. They have the static beamforming design with a radio tied to each antenna set, so we get more capacity along with stronger SNR in client connections. I've been told this is the same as what cell towers use. My question is, if this type of design has been proven by the cell guys, and I love these array...how come other vendors haven's seen the light and copied Xirrus?

  4. Proper antenna design is something that has largely been ignored by most vendors, partially because of the huge success of Wi-Fi in the consumer market where basic omni antennas are sufficient for best effort data networking, and also largely because of the resiliency of Wi-Fi interoperability. I think we're starting to see more advanced solutions now that VoWifi is taking off and wireless is becoming mission-critical for many organizations, which require more sophisticated solutions for challenging environments. Also, wireless client densities are exploding, and require greater cell densities, interference avoidance, and changes to basic design principles. Give it time, we'll see more antenna innovation now that Xirrus and Ruckus are gaining market traction and will force the market leaders to follow suit to remain competitive.

  5. If you have the inclination, I would be interested in seeing this tested again with 3600's running the latest code. Thanks

  6. I would like to test ClientLink 2.0 with the 3600 APs as well. Unfortunately, I don't have any of those APs yet.


  7. Just curious: Have you tried this test with any voice clients?

  8. Do you know particular devices that support APs with implicit or explicit beamforming? It seems beamforming feature of APs will be useless if the client doesn't respond a feedback matrix.

  9. Now that ClientLink is enabled by default and removed from the WebGUI (7.2 onward), it would be interesting to retest it with new code and the 1142 or 3502 APs (and also 2602 and 3602 APs, if available). I've always been suspicious of ClientLink, and only started recommended it be enabled once it became the default.