Brian's Brain

Back in January of 2007, I bemoaned the blizzard of 'draft' 802.11n gear at that year's Consumer Electronics Show, whose presence acted as a constraint on continued evolution of the under-development next-generation Wi-Fi standard. More than two years later, the IEEE is still slaving away on the specification, although tentative indications suggest that the approval work (albeit perhaps not the pending lawsuits) may wrap up by year-end. And within a mid-2008 interview with Broadcom's Stephen Palm, I grumbled about the fact that the draft standard allowed for access points (and access point-containing routers) to optionally support either 2.4 GHz or 5.8 GHz (but not necessarily both) ISM bands, pointing out the market confusion that might result while simultaneously acknowledging the cost-driven motivations for the decision.

Well, folks, the situation is about to get even more muddled, if information I obtained in a recent conversation with a knowledgeable source (who prefers to remain anonymous) is true. As such, I welcome feedback from other participants in the 802.11n standards process as a means of refining my and my readers' knowledge. First off, my informer reminded me that not only do access points and routers not need to support both the 2.4 GHz and 5.8 GHz bands, LAN clients are also free to optionally implement either-but-not-necessarily-both wireless channels. Imagine the situation: a typical tech-inept consumer buys an 802.11n router and 802.11n-inclusive notebook PC, but can't get them to talk to each other. Practically speaking, the likelihood of such a scenario is slim, because 802.11n-based gear that supports only one ISM band is apt to focus its attention on 2.4 GHz in order to achieve backwards-compatibility with pervasive 802.11b/g. But then again, sitting to my left as I type these words is a consumer-targeted 5.8 GHz-only 802.11n access point...

Even more bewildering is the relationship (or, perhaps more accurately, lack of relationship) between 802.11n-cognizant equipments' MIMO antenna arrays and the number of simultaneous stream transfers they support, along with the dearth of product documentation regarding these specifications. Wikipedia concisely spells out the terminology:

The number of simultaneous data streams is limited by the minimum number of antennas in use on both sides of the link. However, the individual radios often further limit the number of spatial streams that may carry unique data. The a x b : c notation helps identify what a given radio is capable of. The first number (a) is the maximum number of transmit antennas or RF chains that can be used by the radio. The second number (b) is the maximum number of receive antennas or RF chains that can be used by the radio. The third number (c) is the maximum number of data spatial streams the radio can use. For example, a radio that can transmit on two antennas and receive on three, but can only send or receive two data streams would be 2 x 3 : 2.

The 802.11n draft allows up to 4 x 4 : 4. Common configurations of 11n devices are 2 x 2 : 2, 2 x 3 : 2, and 3 x 3 : 2. All three configurations have the same maximum throughputs and features, and differ only in the amount of diversity the antenna systems provide.

I've just had a look at the retail packaging and documentation (both printed and online) for around a dozen examples of 802.11n-supportive gear here at the home office; three laptops, my Apple TV and Media Center Extender, and an assortment of routers, access points, bridges and adapters. In no case can I find any mention of either the particular piece of equipment's MIMO antenna array structure or its peak number of supported streams. Thinking back to my recent (and unsuccessful) attempts to stream high-definition, high-bitrate video around the abode exclusively using 802.11n, simultaneous stream limitations could explain the setbacks, except that I happen to know that my Apple router is a 2 x 2 : 2 setup. Even if the LAN clients on either end of the wireless chain are only single stream-capable, I should have had no problems doing the transfer with my particular function-limited experiment. More generally, though, if one of the clients is a wireless bridge containing a multi-port switch, and if more than one of the peripherals connected to that switch is simultaneously attempting to transfer data...

The current 802.11n specification working draft, so says my anonymous source, requires that access points and routers containing them deliver 2 x 2 : 2 or better transfer rate capabilities, while allowing LAN clients to drop down to 1 x 1 : 1 levels. Its aspirations differ, however, from the certification requirements of the Wi-Fi Alliance, an organization that ramped up its activities in the absence of formal specification approval as a means of jump-starting the market transition to 802.11n. Like the IEEE, the Wi-Fi Alliance requires that 802.11n access points and routers be 2 x 2 : 2 or better. However, with respect to LAN clients, the Wi-Fi Alliance differentiates between:

• PCs, which are required to simultaneously receive two streams but only need to support single-stream transmissions, and
• 'Mobile devices', for which single-stream support for both transmit and receive operations is acceptable

I acknowledge the cost-versus-performance background to this differentiation, but the split between the two categories is imprecise. Consider the laptop...specifically, consider the especially cost-sensitive netbook. Is it a PC, or a 'mobile device'? And what about the 'low-power 802.11n' mode supposedly coming in the next-generation iPhone and iPod touch? Does this feature simply mean 'single stream-capable', or will these devices also artificially limit the maximum per-stream bitrate as has been done by some suppliers in the 802.11b and 802.11g past? Will anyone ever know the answer to this question, save for Apple and Broadcom?

As 802.11n matures, two- and three-stream-capable clients (transmit? receive? both?) and three-stream-capable access points and routers (ditto?) will inevitably become more common as suppliers strive to differentiate themselves. But unless the gear's capabilities and limitations are clearly documented and intuitively understandable to potential end users, the end result will inevitably be a combination of implementation frustration and purchase paralysis. My anonymous source represents a semiconductor supplier, and our conversation was as much a request for my advice as it was an information transfer to me. Here's what I suggested, and I'll make sure my contact also monitors this writeup's comments for your insights:

• Translate peak bitrates into more broadly understandable, application-tailored terminology. Since each bonded 40 Mhz channel is claimed capable of 150 Mbps peak transfers, two-stream equipment is supposedly '300 Mbps' and three-stream gear is '450 Mbps'. However, instead consider using alternate terminology such as 'value', 'standard', and either 'premium' or 'turbo'. Or, from an application-centric standpoint, employ 'standard-definition video-capable', 'high-definition video-capable' and 'high-definition video multiple stream-capable'. Or something like that.
• At minimum, get all of your systems customers to use consistent terminology. This'll give consumers interoperability confidence with gear from different OEMS all based on your common silicon foundation.
• Ideally, get together with your semiconductor competitors and agree on common terminology that all of your aggregate customers can employ. While I realize that you vigorously compete against each other in the marketplace, a little bit of simultaneous cooperation will go a long way towards dramatically growing the size of that marketplace. And it's much easier for five or so silicon suppliers to agree than it is for 50 or more systems manufacturers to coordinate their verbiage efforts.

At times like these, I remember a conversation I had a few months ago with my good friend, Terry, who like most folks isn't a techie. Terry explained to me how bewildered he often felt at Fry's Electronics (or any of its brick-and-mortar and online retailer equivalents). All he sees are bit rate, clock speed and other nebulous numbers on the sides of product boxes, with no explanation of what they translate to in terms of end use abilities. If that translation existed, it'd enable him to balance capabilities against product price tags in order to pick something that was optimum for his particular needs.

In healthier past economic times, someone like Terry would be likely to just grab the box with the biggest numbers on its side; Intel, for example, famously sold consumers ever-faster CPUs (regardless of what those consumers actually needed) for many years based on this pragmatic reality. But these aren't healthy economic times, and I therefore suspect that right now, confused consumers will be highly likely to just keep their wallets in their pockets and make do with the gear they already own. That's no way to rebound from a recession. But convincing customers to spend again will require fresh thinking. Are you up for the challenge, readers?