Features

Honeyball: Clever thinking needed before wireless PC integration works

The arrival of GPRS data services is opening up new possibilities for connecting your laptop back to your corporate network. However, a few stiff caveats are in order - this is very early days indeed, and it shows when you look beyond the Powerpoint hype of a number of vendor products and solutions.

The Nirvana that we are working towards is to have a triple tier networking infrastructure in place. When in the office, your laptop can connect via normal CAT 5 cable at 100Mb. Its an ideal solution for large scale OS installation, application software updating and for image-based backing up. But it does require a network cable and an available socket.

The next level of connectivity is provided by 802.11b wireless running at 11Mb. It might not be stupendously fast, but it works extremely well within a well designed office, especially if you have a number of base stations scattered around your organisation. There are issues of security, of course, and WEP encryption is arguably not strong enough yet. But this will come, especially in the 802.11a specification which runs at 55Mb, due later this year.

Finally, we need a solution which works when you move outside of the very localised environs of the office space itself. Maybe into the carpark, or when sat in the cafe at a Motorway service station. Much hype has been made of the possibilities for localised 802.11 networks in those spaces, but little if any has ever been implemented due to the extreme narrowmindedness of the Home Office. And although such micro-networks are fine as far as they go, you will not be wanting to run unencrypted sessions back to your corporate network through such a shared facility. It is here that GPRS really shines.

To make this work, we need a seamless transition from one network to the other, depending on which one is available at the time. And we need a set of simple rules too, to ensure that the most appropriate one is used. For example, when you are in your office building, you might well have all three available to the machine at that moment - wired, 802.11 and GPRS. But it would be mad to use anything other than wired. Unplug the laptop, and it should switch, on the fly, to 802.11. Walk out of the building and into the carpark, and it should move again to GPRS.

However, such a simple and logical set of network switching requires some clever thinking. As things stand, GPRS services "look" like modems to your PC. You have to explicitly dial and make the connection, and break it off when you are finished. This does not sit happily with the capabilities of wired and 802.11 network protocol stacks.

In addition, you need an operating system which can properly handle such a network transition. In other words, although you need the TCP/IP connectivity to be seamless and to "just work", it is vitally important that your workloads and ongoing tasks actually notice that the bandwidth has gone from very fast to relatively slow, and from free to potentially rapaciously expensive.

Here's an example - you start the download of a 600Mb file while in the office: it gets to 500Mb so you reckon its OK to go home now. You unplug from wired and go to 802.11 as you are packing your briefcase, and the throughput drops dramatically. So by the time you leave the building and get into your car and thus onto GPRS, you still have 50Mb left to download. It would be very unhelpful if your laptop decided that since GPRS was the only available protocol stack, it would use this irrespective of the type of download. 50Mb would easily blow your monthly subscription model to GPRS, and land you with a bill for tens of pounds on the current pricing schemes.

We need the OS to "know" that the networking state transition has happened. This is not hard, because Windows (like any decent OS design) is message based. The OS sends power management messages around all the applications, for example, when you do a dock or undock, or any type of system change of that type. This needs to be extended to include protocol stack change, so that applications can, on the fly, make intelligent decisions about how they are working. Another example would be Outlook - when you move to a "slow and expensive" GPRS connection, it would be possible for Outlook to automatically change its behaviour so that it didn't download attachments unless you really asked.

As you can see, really making seamless networking in the pervasive computing space work requires careful thinking and some planning. It also requires small tweaks to the OS and appropriate care and attention in the applications.

Here is a disaster scenario for you which shows the current danger: you have a "road warrier" salesman who works out in the field. He uses GPRS all the time, because it gets him connected back to the corporate LAN. Then he has to come into the office to work on a project, or do training, for two weeks. Whilst he is there, the IT manager remembers that the laptop really needs Office XP instead of Office 2000, and a complete new build of the line of business database application too. So the IT manager connects to the laptop via "the network" and sends down all the data.

It is only when the bill arrives at the end of the month that anyone realises that the salesman's laptop was still working via GPRS, not the 802.11 or wired network. Do the sums on an Office XP installation and a line of business application installation, and apply a pound-per megabyte costing to it.

Deeply scary, isn't it?