The Wi-Fi Alliance announced a new wireless networking specification which will enable devices to establish simple peer-to-peer wireless connections without the need for a wireless router or hotspot. Wi-Fi Direct has a wide array of potential uses, many of which encroach on Bluetooth territory and threaten to make the competing wireless protocol obsolete.
The new spec, previously referred to by the codename 'Wi-Fi peer-to-peer' (does it count as a 'codename' if it is just called what it is in the simplest possible terms?), will be finalized soon and the Wi-Fi Alliance expects to begin certifying devices as Wi-Fi Direct compliant by mid-2010.
"Wi-Fi Direct represents a leap forward for our industry. Wi-Fi users worldwide will benefit from a single-technology solution to transfer content and share applications quickly and easily among devices, even when a Wi-Fi access point isn't available," said Wi-Fi Alliance executive director Edgar Figueroa. "The impact is that Wi-Fi will become even more pervasive and useful for consumers and across the enterprise."
In theory peer-to-peer wireless networking already exists. In addition to connecting to wireless routers or hotspot networks, many wireless devices are capable of creating an ad hoc network-- basically a peer-to-peer wireless network between two devices.
Ad hoc wireless networking has always been more complex and cumbersome than it is worth, and it maxes out at 11 Mbps. Wi-Fi Direct will connect at existing Wi-Fi speeds -- up to 250 Mbps. Wi-Fi Direct devices will also be able to broadcast their availability and seek out other Wi-Fi Direct devices.
Wi-Fi Direct devices can connect in pairs or in groups. With Wi-Fi Direct only one of the devices needs to be compliant with Wi-Fi Direct to establish the peer-to-peer connection. So, for example, a Wi-Fi Direct-enabled mobile phone could establish a connection with a non-Wi-Fi Direct notebook computer to transfer files between the two.
Wi-Fi Direct overlaps into Bluetooth territory. Bluetooth is a virtually ubiquitous technology used for wireless connection of devices like headphones, mice, or the ever-popular Bluetooth earpiece sticking out of everyone's head. Bluetooth uses less power, but also has a much shorter range and slower transfer speeds. Wi-Fi Direct can enable the same device connectivity as Bluetooth, but at ranges and speeds equivalent to what users experience with existing Wi-Fi connections.
There are potential security concerns that come with a technology like Wi-Fi Direct. Bluetooth has been the subject of security issues like Bluejacking which enables an attacker to connect anonymously with an insecure Bluetooth device and hijack it or compromise its data. Bluejacking is only a threat in a radius of 20 or 30 feet. Wi-Fi ranges are much greater which opens the possibility of attackers making anonymous connections from the parking lot or across the street.
The Wi-Fi Alliance, which includes members like Cisco and Intel, is aware of the security concerns as well as the risks Wi-Fi Direct could introduce for enterprise networks. Wi-Fi Direct will include support for WPA2 (Wi-Fi Protected Access 2) and AES encryption for more secure connections and measures are being developed to enable IT admins to exert some control over Wi-Fi Direct networks within their environment.
Showing posts with label Bluetooth. Show all posts
Showing posts with label Bluetooth. Show all posts
Friday, October 16, 2009
Tuesday, April 28, 2009
Bluetooth is now as fast as Wi-Fi
Let's talk about how Bluetooth got as fast as Wi-Fi.
Bluetooth 3.0
High Speed Bluetooth has stopped being chained to the low-power, low-throughput radio that has been both its strength and its weakness. Newly developed code lets Bluetooth applications now run over 802.11g wireless connections in the 2.4GHz, with a throughput jump to 20M to 24Mbps, from 1M to 3Mbps.
One of the key creators of this bit of wizardy is Kevin Hayes, a technical fellow with Atheros Communications, who has worked in more 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 may be 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 speed" in labeling it).
Is this such a big change?
It's a generational change. The Bluetooth SIG wanted something a) that would deliver five to ten times the performance of current Bluetooth b) that would be available to customers in a short timeframe and that was proven technology.
Gartner analysts picked Bluetooth 3.0 as one of eight hot mobile technologies to watch.
With 3.0, the Bluetooth stack exploits whichever radio link is best. Firstly, 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.
There are many object and file transfer protocols and profiles that would happily use it. Things like file transfer, object push, printing, imaging: all these would involve taking some object or file from one device and moving it 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 are currently 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 sent data packets from the Bluetooth stack, and broadcasts these over 802.11.
How does it do that?
It removes part of the Bluetooth stack header and replaces it with the 802.11 header, and sends this to the 802.11 MAC for transmission. And it reverses this process when you're receiving a Bluetooth 802.11 packet.
How complicated was this?
What was the most challenging or puzzling thing 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.
How 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 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.
How does adding this new translation step affect performance?
There's no performance loss, because there's no need for any queuing in the adaptation layer and this is normally where 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 the classic vanilla flavoured Bluetooth.
What about the reverse? How does the Bluetooth stack receive packets at 20Mbps to 25 Mpbs from the 802.11 stack?
That part of the Bluetooth stack is not standardised. So if a mobile phone manufacturer did nothing in their 3.0 implementation to address this, you might have performance issues. You must make changes to this layer to perform at high speeds with 3.0, by adding resources for queuing.
How big a problem is that technically?
It's well within the developers capabilities to address these issues.
What parts of the stack do I have to look at to optimize performance?
This is simply the same exercise you would go through for Bluetooth as you would for adapting your network stack for gigabit Ethernet. You are on familiar ground here.
What will users see?
Clearly, to benefit from the high speed connection, you'll need two devices with the new 3.0 silicon, e.g. a smartphone trying to send five to ten jobs to a PC. Users will be be shown a simple menu option on their smartphone, saying "send to Bluetooth" or a simple Bluetooth menu. They would go through the same motions as they do now, in transferring data but it would just happen faster.
When will they see it?
Nine to 12 months is the time frame, according to the Bluetooth SIG. If you are wanting a smartphone with Bluetooth and 802.11, you'll have to wait for the next version of the phone to come out. I am sure the manufacturers and providers will rush to get these on the shelves as quickly as they can when the technology is available.
Bluetooth 3.0
High Speed Bluetooth has stopped being chained to the low-power, low-throughput radio that has been both its strength and its weakness. Newly developed code lets Bluetooth applications now run over 802.11g wireless connections in the 2.4GHz, with a throughput jump to 20M to 24Mbps, from 1M to 3Mbps.
One of the key creators of this bit of wizardy is Kevin Hayes, a technical fellow with Atheros Communications, who has worked in more 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 may be 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 speed" in labeling it).
Is this such a big change?
It's a generational change. The Bluetooth SIG wanted something a) that would deliver five to ten times the performance of current Bluetooth b) that would be available to customers in a short timeframe and that was proven technology.
Gartner analysts picked Bluetooth 3.0 as one of eight hot mobile technologies to watch.
With 3.0, the Bluetooth stack exploits whichever radio link is best. Firstly, 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.
There are many object and file transfer protocols and profiles that would happily use it. Things like file transfer, object push, printing, imaging: all these would involve taking some object or file from one device and moving it 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 are currently 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 sent data packets from the Bluetooth stack, and broadcasts these over 802.11.
How does it do that?
It removes part of the Bluetooth stack header and replaces it with the 802.11 header, and sends this to the 802.11 MAC for transmission. And it reverses this process when you're receiving a Bluetooth 802.11 packet.
How complicated was this?
What was the most challenging or puzzling thing 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.
How 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 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.
How does adding this new translation step affect performance?
There's no performance loss, because there's no need for any queuing in the adaptation layer and this is normally where 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 the classic vanilla flavoured Bluetooth.
What about the reverse? How does the Bluetooth stack receive packets at 20Mbps to 25 Mpbs from the 802.11 stack?
That part of the Bluetooth stack is not standardised. So if a mobile phone manufacturer did nothing in their 3.0 implementation to address this, you might have performance issues. You must make changes to this layer to perform at high speeds with 3.0, by adding resources for queuing.
How big a problem is that technically?
It's well within the developers capabilities to address these issues.
What parts of the stack do I have to look at to optimize performance?
This is simply the same exercise you would go through for Bluetooth as you would for adapting your network stack for gigabit Ethernet. You are on familiar ground here.
What will users see?
Clearly, to benefit from the high speed connection, you'll need two devices with the new 3.0 silicon, e.g. a smartphone trying to send five to ten jobs to a PC. Users will be be shown a simple menu option on their smartphone, saying "send to Bluetooth" or a simple Bluetooth menu. They would go through the same motions as they do now, in transferring data but it would just happen faster.
When will they see it?
Nine to 12 months is the time frame, according to the Bluetooth SIG. If you are wanting a smartphone with Bluetooth and 802.11, you'll have to wait for the next version of the phone to come out. I am sure the manufacturers and providers will rush to get these on the shelves as quickly as they can when the technology is available.
Subscribe to:
Posts (Atom)