I already wrote about how Bluetooth is specifying Wi-Fi for its high bandwidth transport in a future version. Now there’s another interesting Bluetooth/Wi-Fi juxtaposition.

You may remember that last year Bluetooth subsumed WiBree as an ultra low power consumption variant. Now something analogous is happening in Wi-Fi, where a startup called Ozmo has come up with an ultra low power variation of Wi-Fi, which it is pitching as a substitute for Bluetooth.

Ozmo is not the first to propose this. Nanoradio claims that its implementation of Wi-Fi consumes way less power than Bluetooth, and they have a reference design for a Wi-Fi headset to demo the concept. Atheros has also recently announced a low-power Wi-Fi chip - so low that they claim “near zero” stand-by power consumption.

So Ozmo may not be so radical in its low-power claims, but it also claims low-cost. The Ozmo chip is priced the same as Bluetooth chips, which Ozmo estimates are between 1/4 and 1/3 the cost of Wi-Fi chips.

The Atheros and Nanoradio chips are full implementations of Wi-Fi; Ozmo’s is, according to this EETimes article, a “stripped down” version. This may mean that it is a non-standard version, in which case it would need a new certification program from the Wi-Fi Alliance - not a major obstacle, I presume, in view of Intel’s strong support for Ozmo.

So why would anybody want a version of Wi-Fi to substitute for Bluetooth, when we already have Bluetooth? Well, while most phones come with Bluetooth these days, in the PC world Wi-Fi is far more common than Bluetooth. So for peripherals designed exclusively for PCs, like mice and keyboards, Wi-Fi makes more sense than Bluetooth simply on the grounds of out-of-the-box compatibility. Add the technical benefits, like coexistence (Bluetooth and Wi-Fi tend to step on each others’ toes) and superior performance (Ozmo claims double the battery life in similar applications to Bluetooth), and it seems like a no-brainer.

The factors that could cause it to fail are ease of use and price. The setup of the peripherals with the PC must be completely automatic, and the operation of the devices must be flawless. Peripheral manufacturers must produce Wi-Fi versions of all their wireless products, and price them the same as their Bluetooth versions. The Wi-Fi drivers on the PC side will have to be modified in order to permit the PC Wi-Fi to communicate simultaneously with access points and peripherals. This is being done anyway by Intel, in a project called “Cliffside.”

All these impediments are mitigated considerably by Intel’s involvement. Intel makes most of the Wi-Fi chips in PCs, and presumably these chips will support the Ozmo products. With this assurance, peripheral manufacturers will feel comfortable going ahead with Ozmo-powered products.

The Intel Atom is aimed at Internet tablets, Mobile Internet Devices and Ultra-mobile PCs (or whatever the nom de jour is), but not at phones. I don’t think Intel has formally announced its return to the phone processor business yet, but Paul Otellini has been talking about it for a while now, so it seems overdue to make it official. That’s what the Financial Times did today with the headline “Intel to re-enter mobile market.” Otellini said the same thing to the New York Times on Sunday as well. Of course it has been expected ever since the first Atom announcement, and it may not really qualify as news, but here it is: “A second generation version of the chip, expected in late 2009, will be aimed at smart phones.”

As you know, the Atom is Intel’s prospective ARM-killer, but Intel will have some very heavy sledding to do to achieve this goal. The first obstacle is size and complexity. The Intel Architecture instruction set is much more complicated than the ARM, with decades of legacy dross gunking it up. The core proposition of IA for handsets is that IA is compatible with all the PC software and websites out there, so none of the legacy stuff can be left out. Intel has two factors working in its favor for this issue: first, a lot of the little-used functionality of IA can be implemented in microcode, which takes minimal die space. Second, Intel leads the world in process technology, and as it moves to the 32 nm and below nodes, vast numbers of transistors can be fitted into tiny chips. This shrinkage, and advances in power management technology, may enable the next generation of Atom to get into the same ballpark as ARM for battery life.

The second obstacle is incumbency. There are vastly more ARM processors out running in the world than there are Intel Architecture processors. The ARM is the processor used by effectively all phones and smart phones, and there are even more ARMs in other embedded applications. While Intel can point to a huge independent software developer community for IA, with a rich array of third party developer support, so can ARM for its architecture. And it’s not clear that the Atom will have a significant performance advantage over the ARM. ARM is not standing still on its architecture, delivering faster, lower power chips in step with Moore’s law just like Intel.

The incumbency issue also has a political aspect. Handset manufacturers are disinclined to hand Intel the kind of architectural franchise that it has in the PC world, so the Atom will have to have a compelling, essential advantage over the ARM in order to displace it in any but niche applications. Intel hopes that “the real Internet” is that advantage, but the iPhone has demonstrated that the real Internet can run very nicely on an ARM-based phone. In any case, within three years more smart phones will be shipping than PCs, and the other handset manufacturers will probably have caught up with Apple on the browser front, so it is possible that more Internet browsing will be being done with ARMs than IA chips.

The third obstacle is business model. To satisfy the stock market, Intel requires aggregate gross margins around 60%. This will be very tough to achieve in the mass-market for handset processors, because the margins on competing ARMs are much lower.

Good background on the Atom can be found in this EETimes article, this Beyond3d article, and this one by my colleague Linley Gwenapp.