Solving the Multi-Network Wireless Problem

 
 
By Jim Louderback  |  Posted 2003-11-10
 
 
 

Solving the Multi-Network Wireless Problem


Last week, I wrote about how VOIP, cellular and WiFi will combine to make traditional phones and POTS obsolete. But based on a discussion I had with a development manager at Intels Systems Technology Lab, there are still some thorny problems that need to be resolved.

First some background. Intel has put together an internal group of scientists and researchers to help realize its vision of seamless access to information from any device, using any available network. One project theyve been working on is a "universal communicator," designed to communicate on 802.11 and GSMs data network, along with network 3D gaming, video and audio playback, and other media capabilities.

It turns out that the device itself isnt hard to build. Although Intels grand plans for a single tunable radio, built onto a CPU, is still mostly fantasy, putting multiple radios into a single device isnt hard. Instead, network and radio co-ordination present the biggest challenge. "Its a huge task," explains Intels Bryan Peebler. "Ultimately, you want to get a single reconfigurable radio," he adds, "but thats still years away."

Intels prototype universal communicator includes a GSM GPRS radio, and an 802.11b radio. Intels recent purchase of Mobilian seems to suggest that Bluetooth should be incorporated pretty quickly as well. Once you put multiple radios in a device, you then have to ensure that they dont step all over each other as they communicate.

There are two different types of interference. The first, frequency interference, occurs when two radios transmit on the same frequency. Bluetooth and 802.11b, for example, both work at 2.4 GHz and can be a problem. The solution, according to Peebler, is to "time-slice between 802 and Bluetooth so they dont step on each other."

The other big problem: analog interference. Thats what you get when a poorly shielded component generates so much noise that a radio transmitter/receiver cant do its own job. "In our device, weve done some interesting stuff on radio placement and shielding" to cut down on analog interference.

Once youve solved the physical-interference problems, you run into network coordination issues, which are much harder to resolve. "Our premise is that it is reasonably simple to put two radios in a device. Its more difficult to make them work together to add value to the user."

Next page: How users can navigate voice and data connections.

Roam If You Want


To">

"Adding value" means allowing the user to roam both voice and data connections from slower cellular to faster 802.11 networks—without dropping calls, losing packets or sacrificing voice quality. It should be seamless.

Heres where the carriers have to step up. Once the phone is able seamlessly to select the fastest (or cheapest) network that it sees, the voice and data providers need to support the switch from one to the other. Ideally the cellular network would see its VOIP-to-voice cloud bridge as just another cellular node that would let a call switch from GSM to 802.11b just as it would move from cell tower to cell tower.

According to Peebler, these problems are not intractable. Intel, along with a number of cellular and equipment providers, are working on the issues. One way around it: Have your corporate PBX handle the call switching, essentially allowing the PBX to connect to your cell phone, while keeping a persistent VOIP connection live to whomever youre calling.

Another way would be to add a box to the operators premise location and treat your 802.11 access point as just another cellular base station.

One of the big problems, though, is deciding when to hand off from 802.11 to cellular. We all know how tenuous wireless LANs can be. Should you automatically switch when you walk behind a wall, for example, and temporarily lose the LAN connection? Whats the threshold? One packet? Ten? One hundred?

Another issue: When youre on a cellular call, what happens when you come within range of an 802.11 hub? Will the system try to connect automatically? What if its at Starbucks or McDonalds, and you dont have a subscription? Those issues need to be worked out as well—but built-in GPS and some kind of location awareness will help. It would be great if your communicator knew when you were in the office or at home, and used that knowledge to attempt to force an 802.11 connection – but while on the street, it eschewed just any old dirty-net it happened across.

Finally, what about using both networks simultaneously? What if youre on a voice call on cellular, but your communicator detects an 802.11 signal? It would be great if it could start downloading e-mail and attachments in the background while you finish your cellular-based call—or even multiplex the two networks together for more bandwidth. But thats even harder.

The good news is that these problems are being addressed. According to Peebler, well see devices next year that will be able to use both Wi-Fi and cellular networks sequentially. Itll be another year before we see simultaneous network use and automatic roaming between the two. As for GPS, Bluetooth and other networks? Itll be 2006 at the earliest.

Hmm. Perhaps we wont see the baby bells vaporize by 2007. But I still think their days are numbered. That number might just be a bit higher than I thought, but its still finite!

Want more information on Intels communicator project? You can find it at Intels site.

eWEEK.com Wireless Center Columnist Jim Louderback is editor in chief of Ziff Davis Internet.

Rocket Fuel