[Previous entry: "El Margarita Perfecto"] [Next entry: "running linux, again"]

07/30/2004: "11g is fine, dude."

Wow... seems that now at least one company is now attempting to use my words to support their product. In this "blog entry" (which is nothing more than an ad for their product).

They claim, "Even with an AP in every cubicle there is no co-channel interference".

Note how the movie demos APs based on 802.11a *NOT* 802.11g. A bit of slight-of-hand, perhaps?

Here's the truth, you can't eliminate co-channel interference by tuning all the APs to different channels, given the restrictions on the number of channels in 802.11g. The myth of "3 non-overlapping channels" in the 2.4GHz ISM band is just that, a myth. While the channels don't overlap, the receivers don't have enough adjacent channel rejection (ACR) to deal with a strong (i.e. closer or high-EIRP) signal on an ajacent channel.

This, by the way, was what doomed Vivato's "multi-channel" dream. Even if you build the world's best WiFi receiver, and it somehow magically posesses 100dB of ACR, and co-locate two or three of these (in order to have a multi-channel AP), the clients, which don't have these super-radios, will interfere with each other, and the signals from the adjacent channel "APs" will also result in potential adjacent channel interfernce (ACI).

For these same reaons, Engim is also challenged to reach their goals for capacity enhancement via multi-channel operation.

But back to Propagate, the claim is easy to refute. If Propogate puts an AP in every cube, then nearly every AP has four neighbors (in the adjointing cube on each side.) Using the 8 channels present in the lowest 2 U-NII bands, we have 200Mhz of spectrum to deal with. 802.11a defines 8 channels in that spectrum, at 25Mhz centers. For the sake of discussion, lets label these channels 1-8. (The 802.11 standard uses 34-64 as channel identifiers for this part of the U-NII bands.)

If we had 3 neighbors, then each AP could be on an alternate channel (1, 3, 5, 7 or 2, 4, 6, 8), but we don't. We have 4 neighbors, so at least 3 APs will have neighbor APs on adjacent channels. For instance, 1, 2, and 3 or 5, 6, and 7. These three APs are extremely challenged to run simultaneously. If AP #1 is receiving a frame from one of its clients, and AP#2 transmits, then the frame arriving at #1 will be rendered un-recoverable. In a similar manner, if AP#1 is receiving a frame from one of its clients, and a client of AP#2 sends to AP#2, but the signal also arrives with enough power, it will also smash the frame arriving at AP #1.

At 6Mbps, the IEEE standard requires 16 dB of adjacent channel rejection. The amount of ACR required by the standard is lower as the modulation rate increases. At 18Mbps the IEEE standard requires 11dB of ACR. At 54Mbps, the ACR required by the standard is -1dB. While some chipsets perform above these requirements one has to assume that the clients perform at the minimum, since there is no way to control what client will wander into the room next.

If a 54Mbps 802.11a signal leaves a AP2 while AP1 is receiving, at 16dBm (11dBm tx power + 5dBi of antenna gain), it looses at least 47dB in the first meter, assuming free space path loss. Lets allow 10dB of additional attenuation for the signal to pass through the partition wall, and increase the path loss exponent to 3.5 (a normal 'closed office' estimate), and estimate that the signal travels 2m total. Here we've attenuated the signal 67db, so our signal arrives in the ajointing cube at -50dBm. The AP in the ajointing cube, running on an adjacent channel attempting to decode a packet at 54Mbps has an ACR of -1dB. Presto, the result is interference, but for one thing. That -50dBm signal from the adjacent AP probably set CCA on all the APs around it (at least those operating on adjacent channels.) In this case, the second AP won't send its packet until the protocol allows it to do so.

Something else I noticed. Watch the video closely and note that they're installing the APs inside the desks in the cubicles. By doing this, they may have attenuated the signals far enough such that the APs in each cube really do operate independently. Its difficult to estimate without being present, but a better 'test' (demo?) would be if they set all of those APs ON TOP of the cubes.

Propogate will counter that they also tune the power level. I contend that turning the power down isn't much of a solution. There are two problems. The first problem is that the PAs used in most cards (and APs) won't run below a power level of about 5dBm. If you'll re-run the numbers above, we still have a signal arriving in the adjacent cubicle at -60dBm or so, still to high by a lot, and still high enough to set CCA. The second, and more difficult problem is that there is no way in the (current) 802.11 standards to tell a client to tune its power. 802.11h and TPC may be an answer, someday, but the 802.11h standard was only approved in September of last year, and implementation even after a standard is approved could take years, though perhaps the requirements of the new FCC spectrum and the regulations in Europe will drive this faster.

I'm sure that the software produced by Propagate does attempt to find an optimal solution, and often does, but if it does, and throughput is preserved, it is likely only because the APs (or their clients) have to set CCA for the adjacent channel APs.

If the people at Propagate want to debate this (in public), then I welcome them. The math is straight-forward. BTW, I was specficly referring to 11g in my post. Propagate demos 11a. The reasons why may be clearer now.

In the end, 11g will be used by a large number of residential users, and very few enterprises. Where 11g is used in the enterprise, Vivato's new product is one good way to do so. I still think that Enterprise users will go with 802.11a in the Enterprise, and 11b/g at home or on the road.

mahalo,

Jim

p.s. I love the "flanger" effect while the CTO is talking. Takes it down a notch.