Revisiting Wi-Fi Interoperability Certification: Devil is in the Details

Revisiting Wi-Fi Interoperability Certification: Devil is in the Details

By CWNP On 04/06/2010 - 24 Comments

A vast majority of technologies blossom and wither away. Only a few of them survive the test of time. Wi-Fi seems to be one those robust technologies. It has transformed not just the way people work, but the way they communicate and play. Wi-Fi was initially designed to be a (yet another) technology to connect notebooks and computers to networks, but now it has made its way into all kinds of consumer devices – e.g., phones, PDAs, gaming consoles, cameras, DVD players, televisions. With proliferation of 802.11n, the trend is just going to increase. Hence, there is a strong need to make sure that all the Wi-Fi devices are interoperable.

Yes, I know what you are thinking – the first thing that comes on top of our mind when talking of Wi-Fi interoperability is Wi-Fi Alliance™. Wi-Fi Alliance is no doubt doing a great job in making sure that the Wi-Fi users do not get lost in the jungle of technology. Several thousands of devices have been “Wi-Fi certified™” in the past (and several will be in future). They do interoperate. However, the key question is whether the depth of the interoperability testing is enough.

There have been several instances in the past where Wi-Fi certified 802.11a/b/g devices have not adhered to the 802.11 standard (802.11 MAC Heterogeneity). The good old Cisco Aironet 350 wireless adapter (not sure if anybody remembers it anymore) does not conform to the DCF portion (See 802.11 Arbitration) of the IEEE 802.11 standard. DCF mandates that all 802.11 devices should wait for a certain random back-off interval before they can actually transmit a packet. Without getting into the details of the actual parameters involved, a Cisco 350 series adapter does not wait for the specified back-off interval before packet transmission. Thus, it grabs the medium much more aggressively than any other standard compliant adapter. This functionality technically does not break interoperability, but is unfair – the Cisco adapter has an unfair edge in packet throughput related performance comparisons.

Examples that actually break interoperability follow. Wi-Fi certified APs and clients have very buggy virtual carrier sensing behavior. Intel Centrino adapters (e.g., Intel Pro Wireless 2200 BG) ignore the “duration” field received in a packet when operating in an ad hoc mode (Note: The duration field is used by a transmitter to reserve the medium and is helpful in minimizing packet collisions). Thus, the presence of such devices in your network can affect your network performance. As a result, the virtual carrier sensing mechanisms break down and can potentially degrade network performance. Also, there are wireless adapters that spit out non-standard values in their 802.11 packets – e.g., duration field that is > 32 ms, or specify 802.11 power save mode settings in Control frames. I am sure that this list can grow - each of us can add examples to this list based on the grievances faced in our lab, customer deployment, etc.

Given the above state of affairs with the relatively simple 802.11a/b/g devices, do you think things will be different with the Wi-Fi Certified 802.11n devices, which are much more complex? Can the nature of modern Wi-Fi certification ensure smooth and pain-free operation of 802.11n wireless LANs? Please tune in with your views.
Thanks, Gopi

Tagged with: wi-fi alliance, interoperability, compliance

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.