The Wi-Fi That Never Was

I’ve been fortunate enough to be in the Wi-Fi industry for close to a dozen years now. To a point, having 12 years (vs 4 or 5) doesn’t really help much except that you can reflect on things of yesteryear and hope to sound cool (and old) doing it.

There were quite a number of technologies that were introduced as either a Wi-Fi amendment (or parts thereof) that were never implemented by Wi-Fi vendors. This is by no means a comprehensive list. I’m saying that because for the most part this is from memory and I know I missed something so I needed some kind of out. Ok, on with the list. 

Implicit Beamforming

As one of the many, many enhancements brought to us by 802.11n, beamforming is one that has been talked about much be never been fully realized (11ac fixes that).

In order for beamforming to work properly it has to know how to phase the transmissions to the client. The more accurate the channel information, the more accurate the beamforming will be.

There are two types of beamforming that were specified in 802.11n. Explicit beamforming is the better of the two but requires that the client device support explicit beamforming. Up until 802.11ac, there were no client devices that supported this so it never saw an 11n implementation.

Implicit beamforming does not require client support but has had very mixed results. Cisco is the only company that ever implemented it on the APs (ClientLink) but every test I’ve ever seen doesn’t put it in a good light. That really isn’t Cisco’s fault; implicit beamforming has now been shown by every chip manufacturer to just not work well. Because of that it was decided that implicit beamforming would not go into the 802.11ac amendment.

802.11F Inter-Access Point Protocol (IAPP)

The goal was simple: Standardize communication on the distribution system (typically Ethernet) during the client roaming process. That would enable an AP to forward client information, buffered data etc to the new AP over the wire.  

The real coolness was that it would not only enable a client to roam between APs seamlessly, but between two different vendor APs.  Who the heck would want to do that? Well, the answer was (mostly) no one. From memory, Proxim was the only vendor to implement IAPP.  Heck, if I were them I’d want to interoperate with other vendors too. How else could they expect to get market share?

802.11F was standalone document (denoted by the uppercase F) and never gained traction. It was ratified in 2003 but was officially deemed dead in 2006.  Sorry about that.

802.11T (Wi-Fi Performance Prediction)

Potential Wi-Fi customers hear pitches from every vendor and every one of them includes some sort of test showing them being the fastest thing on the market. But who is a customer to believe? The IEEE tried to solve this problem by establishing a standard for testing Wi-Fi.

The goal was to enable testing and comparison of Wi-Fi systems based on a standard set of performance metrics and testing procedures.  The amendment made it through a significant portion of the process but died before it was completed. The amendment committee is made up of members that also work for Wi-Fi vendors. In this particular case, members of the committee (representing vendors) couldn’t come to an agreement and the amendment was never ratified.

Point Coordination Function (PCF)

The Wi-Fi we know and love today is based on Distributed Coordination Function (DCF) which is a fancy way to say that Wi-Fi is pure anarchy.  

From my observations most people new to Wi-Fi think that the AP is in charge and controls the network. Depending on your point of view this is unfortunately not the case. APs and clients are on equal ground when it comes to accessing the communication medium (the air).

However, there once was a protocol that had it differently.  The “point coordination” part of PCF really means “access point coordination”. PCF put the AP in charge by telling a client when it could and couldn’t talk.  Think token ring for Wi-Fi. This isn’t a lettered amendment that can just be blindly ignored or deleted. PCF has always been (and still is) in the standard but never used as a contention mechanism.

HCCA (Hybrid Coordinated Channel Access)

When 802.11e (QoS) was introduced in 2005 it introduced a significant number of protocol additions to Wi-Fi. Originally, QoS was going to fall within 802.11i (Security) but it was split out when it was realized that both topics were very complicated.

The two main methods for achieving QoS in 802.11e are EDCA (Enhanced DCF Channel Access) and HCCA. EDCA is a math-modified version of the contention system that has been used since Wi-Fi’s inception. It is how QoS is done today. HCCA was a modified version of PCF Mode (see above) that allowed a weighted system for calling on the client STAs. The AP would know which devices were voice, video best effort and background and it would call upon them in an efficient manner to guarantee those access categories. Guarantee is an interesting word there because EDCA cannot guarantee a class of service; it can only give statistical probability to each access category.

I have to give mad props to my man Ben Miller. He told me very early on that HCCA was never going to be implemented. I didn’t really understand why because it was, at least from a QoS perspective, superior to EDCA. But sure enough, about a year later the IEEE removed HCCA from 802.11e.

It’s been fun to think back about all the stuff that we had to learn (Thanks Devin!) but never really got to put to good use… until now.

 

GT