The draft 802.11n standard for next-generation wireless LANs failed to garner the 75% of votes required for adoption at last month's Task Group N meeting. This was expected. Many diverse companies have a stake in this standard, and it would have been a bigger surprise had the draft won a supermajority on the first ballot.

However, two serious problems have emerged. First, the draft elicited an unprecedented 12,000 comments, many requiring careful examination. This could delay completion of the 802.11n standard. Second, the draft doesn't guarantee coexistence with legacy WLANs, and doesn't do enough to ensure interoperability between 802.11n devices from different manufacturers. A standard that causes interference with existing WLANs, triggers a deluge of tech support calls and generally frustrates users in mixed-vendor environments is worse than no standard at all.

Three serious technical flaws have been identified so far:

• The specification does not define an access protocol for 802.11n's optional extension channel, which doubles the bandwidth to achieve higher data rates. A separate access protocol for the extension channel would enable spectrum sharing - with good throughput for both 802.11n and legacy 802.11a/b/g WLANs.
• The specification does not take into account existing 2.4GHz channel spacing. As now defined, 802.11n channels are spaced 20MHz apart, while 802.11b/g channels are typically spaced 25MHz apart. When 802.11n uses its optional extension channel (channel-bonded mode), it occupies 40MHz. There is a good chance that 40MHz partially overlaps any nearby legacy WLANs enough to cause interference but not enough to allow orderly sharing. The problem can be alleviated by using 25MHz channel separation for access-control transmissions and selecting default channels aligned with the existing 2.4GHz band channels.
• 802.11n currently defines an optional greenfield preamble. A preamble enables different devices to recognize each other. Based on experience with 802.11b/g standards, mixing devices that look for the preamble with devices that don't adds overhead and creates interoperability problems. Either making the preamble mandatory or removing it completely would benefit efficiency and QoS.

Solutions to these problems are rarely perfect, because interoperability and coexistence require compromise. But the proposed solutions are much better than doing nothing.