Sex, Drugs & Unix

Home » Archives » August 2004 » Meru magic?

[Previous entry: "I like big brains"] [Next entry: "linux in hawaii"]

08/10/2004: "Meru magic?"



Nancy Gohring reports that Meru Avoids Mixed Traffic Penalties


The Meru AP virtually separates 802.11g and 802.11b traffic on a per packet basis. Because the packets don’t see each other, the 802.11g traffic doesn’t switch to a backward compatibility mode, which would require it to communicate with the AP in a way that creates overhead that typically slows down traffic in a mixed environment, said Sarah Kim, senior marketing manager for Meru. Because it is waiting for a patent, Meru is reluctant to disclose more about how the AP works, she said.


And

Chipmaker Engim avoids the problems that typically occur in mixed environments by separating the traffic onto different channels. But Meru is using a single channel, Kim said.

I've covered Engim's problems here before. Its good that we're told that Meru uses a single channel.

For high speeds, 802.11g uses orthogonal frequency-division multiplexing (OFDM), just as 802.11a does. But the protection signal has to be receivable by 802.11b clients, meaning it must be sent using their complementary code keying (CCK) waveform.

The 'slowdown' in 802.11g networks comes when there is but a single 802.11b STA associated with an 802.11g AP. Once this happens, the AP is required to advise all 11g STAs to send "protection" frame (a CTS-to-self frame) ahead of any transmission. This protection mechanism is used to prevent 802.11b clients from transmitting on top of an OFDM transmission. The 11b radios can't decode the preamble from an OFDM packet, so they potentially don't "know" that an 11g/OFDM device is already transmitting.

The standard allows one to turn the protection mechanism off, but its inadvisable if there will be a mix of 11g and 11b clients in the area. Otherwise, range will be impacted when a distant 11b STAs doesn't get CCA set, and transmits on top of an 11g STA attempting to communicate with its AP.

Potentially, Meru has taken the multiple-BSSID idea that I once patented, and used it to provide two virtual APs on one radio. The first virtual AP is a standard 11b AP. It beacons 11b frames, advertises only 11b rates, etc. If a STA attempts to associate at an 11b rate (probe responses, etc), it is associated with the 11b BSSID (and virtual AP). The other 'virtual' AP is an 11g AP, and only accepts assocations from 11g clients. (I'm leaving the details out here, email me for a fuller discussion.)

Thus, all 11b-only clients are associated with BSSID-b, and all 11g-capabile clients are associated with BSSID-g. BSSID-g is configured to never send protection frames, and never advise its associated STAs to do do, and Meru makes its claim.

The problem is that a distant 11b client may attempt to uplink (toward the AP) while an 11g client is already uplinking. Since the 11g STA didn't send a protection frame, and is potentially somewhat distant from the 11b STA (such that the 11b STAs energy detect threshold isn't met), the 11b STA thinks the "air is clear", and sends its frame, smashing the frame that the 11g STA was sending.

Throughput drops.

There is a reason for these protection frames. They're not included in the standard because Task Group g wanted to slow the throughput of 802.11g. Rather, they know that the wireless is a very expensive media to cross, and sacrificing a bit of throughput in order to get the packet through the first time is the right choice.

I could be wrong on the above, since everything I know about Meru is from their website, and they don't provide the details. I'm just thinking out loud here.