Bluetooth last week stopped being chained to the low-power, low-throughput radio that has been both its strength and its weakness. New code lets Bluetooth applications now run over 802.11g wireless connections in the 2.4GHz, with a throughput jump to 20 Megabits per second (Mbps) to 24 Mbps, from 1 to 3 Mbps.
We talked to one of the key creators of this bit of wizardy: Kevin Hayes, a technical fellow with Atheros Communications, who has worked in m ore than a dozen task groups around the IEEE 802.11 wireless LAN standard, and in Wi-Fi Alliance projects such as Wi-Fi Protected Access.
Hayes was the technical editor for the 802.11 Protocol Adaption Layer (PAL), one of the big changes in the just-announced Bluetooth 3.0 specification, a two-year project. PAL, together with the 802.11 media access control (MAC) and 802.11 physical (PHY) layers constitute the Alternate MAC/PHY or AMP, enabling a Bluetooth profile (such as file transfer) to run over a Wi-Fi link. It’s the beginning of “Bluetooth everywhere,” according to Network World blogger Craig Mathias.
But make sure you look for the full formal designation: Bluetooth 3.0 + High Speed (or HS). (For some uses, vendors can deploy 3.0 without the ability to use a Wi-Fi connection but they can’t use “high spped” in labeling it).
So, is this a big change?
It’s a generational change. The Bluetooth SIG wanted something what would deliver five to ten times the performance of current Bluetooth; they wanted something that would be available to customers in a short timeframe; and they wanted something that was proven technology.
With 3.0, the Bluetooth stack opportunistically exploits whichever radio link is best, right?
First, it would only be used if both sides support it, in silicon and software. Some of the classic Bluetooth profiles, such as the headset profile or the hands-free profile for a car kit, will never use high-speed [Wi-Fi] silicon. But there are many object and file transfer protocols and profiles that would. Things like file transfer, object push, printing, imaging: all these would involve taking some object or file from one device to another. The new standard is appropriate for almost all of these.
What happens when the new Bluetooth code is deployed on gadgets with a Wi-Fi radio?
There’s a generic Bluetooth framework, that rides over the classic Bluetooth radio. There are a set of protocols for doing things like discover and negotiation and so on. Some configuration variables [now] are handed over to the new software module, called the 802.11 PAL, which translates those variables from the Bluetooth domain to the .11 domain. It translates the data packets [sent] from the Bluetooth stack, and sends these [out] over 802.11.
How does it actually do that?
It removes part of the [Bluetooth] stack header and replaces it with the .11 header, and sends this to the .11 MAC for transmission. And it reverses this when you’re receiving a Bluetooth 802.11 packet.
How complicated was this? Was there anything especially challenging or puzzling about creating this translation layer?
Bluetooth, as a stack, does have a different set of expectations in its parlance [compared to IP]. For example, the idea of “best effort” in transmission. In IP, best effort means “this channel gets no advanced quality of service.” Bluetooth is not quite like that. In Bluetooth, best effort means it doesn’t get any advanced priority service, but it is a reliable channel anyway.
Another example is the way Bluetooth defines certain channels, for example, for audio streaming: Bluetooth will send packets and retry if they get dropped, but after a certain amount of time has passed, it will stop retrying. While 802.11 also does retries, it doesn’t use time [measurements], but a configurable number of retry attempts.
The PAL layer adapts the intentions of the Bluetooth layer to the capabilities of the features in the 802.11 MAC and PHY [physical] layers.
Does this mess up existing Bluetooth applications or usage?
This [process] is very clean: the Bluetooth stack itself is unchanged. That was very important. The “profiles” in the Bluetooth stack are really the applications. That was a very clear mandate from the Bluetooth SIG that that none of these would change in order to support this alternate MAC/PHY. They didn’t want to have to test all their profiles [all over again].
Does adding this new translation step affect performance?
There’s not performance loss, because there’s no need for any queuing in the adaptation layer, which is how you lose performance in a network stack. The 802.11 stack can accept packets at 20Mbps to 25 Mbps: that’s more than 10 times as fast as [classic] Bluetooth.
But what about the reverse — the Bluetooth stack receiving packets at 20Mbps to 25 Mpbs from the 802.11 stack?
That part of the Bluetooth stack is not standardized. So if a [mobile] phone manufacturer did nothing in their 3.0 implementation [to address this], you might have performance issues. But in order to do 3.0 with what’s called high speed, you must make changes to this layer, by adding resources for queuing.
Is that going to be a problem technically for them?
It’s well within their capabilities to address. What parts of the stack do I have to look at to optimize performance? This is the same exercise you would go through for Bluetooth as you would for adapting your network stack for gigabit Ethernet.
What will users see?
You’ll need two devices with new [3.0] silicon, for example a smartphone trying to send five to ten jobs to a PC. Users will see on the smartphone “send to Bluetooth” or a Bluetooth menu. They would go through the same motions, but it would just happen faster.
When will they see it?
Nine to 12 months is the time frame, according to the Bluetooth SIG. For smartphones with Bluetooth and 802.11 [radios] you’ll have to wait for the next version of the phone to come out.
Editor’s note: The Bluetooth Qualifications Board has certified Atheros’AR3011 Bluetooth chip for PCs,, along with the host stack, and 802.11 a/g/n solutions to support the new high-speed 802.11AMP.
