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 7.0.98.0 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.

-Andrew