Connectivity loss when roaming from AP to AP

[rsamuel708]

I work for a healthcare organization where nurses use what we refer to as COWS, or carts on wheels. These carts are basically laptops attached to carts that utilize our wireless infrastructure to access patient care applications.

The problem we've been having and working with the application developers on is that, whenever the carts are moved between patient rooms and have to associate with a different AP, the telnet connection that the application uses to establish connectivity is dropped during the short delay in the changeover.

Anyone have any experience with settings that might mitigate this? Far as I know there are no telnet timers that can be adjusted(buffered) to help with this situation, and I'm not certain if anything can be adjusted on the wireless network to help. The "fix" has been to have the user reboot to re-establish the telnet session and then everything's good again.

Any suggestions on things to try?

Thanks.

/rls

[rduke]

I assume these are all on the same SSID and same subnet, i.e. there are no layer 3 roaming issues since you did not mention if you use LWAPP APs. In any case I used to roam all the time with telnet sessions to Cisco switches. If it is dropping the session, it is more likely because of the host system. You could test that by testing to a Cisco device.

A couple of suggestions:

1. Use WPA2 instead of WPA. WPA2 handles roaming better.

2. If you are using XP wireless make sure you have the Microsoft WPA2 update installed. Not necessary if you use another wireless supplicant.

3. Test roaming with a laptop from room to room. If you are loosing more than two pings or so, your roaming sensitivity is not working optimally. Use continuous pings.

4. You could go to fast roaming using CCKM; however, I would make sure the standard roaming method is working correctly before going to the effort of changing everything. Besides, you will need to have a wireless client capable of CCKM. If not, you are out of luck. I had that problem with some of my Windows CE devices. They were too dumb to use CCKM.

5. I did have some Windows CE devices which did not roam properly until I had the roaming sensivity set. I was loosing about 7 pings. This is not normal unless you have a problem.

6. Last resort - but expensive. We had an intermediate server that would hold sessions to SAP due to the potential of the same problem you have. The company that provided it to us was Psion Teklogix. It prevented session loss because a server held the session, not the mobile client. A company like this one should be able to modify the application to your needs if you have money to spend.

Testing is the key I think, but WPA2 would have to help due to the caching of authentications. If you go back to a room you were just in, it should roam faster.

Randy

[rsamuel708]

Randy,

We are using LWAPP APs in this particular hospital in combination with WiSM modules. I am new to the Unified architecture so excuse my ignorance, but does this change the suggestions you posted? The SSIDs and subnets are all the same, and we have identified it as an application issue, but your suggestions are useful in determining how we can help the application stay connected.

/rls

[rduke]

That's what I figured. I just wanted to make sure you were not roaming to other subnets.

Some applications seem to be pickier than others. I found a link to the server software we had at my last job. It is pretty cool. Basically, the server holds a session on the host computer. Your wireless client attaches to the server, not the host system. The server will allow your mobile client to resume its session without loosing the connection to the host. It is kind of hard to explain, but basically it allows session resumption even with complete loss of the wireless. The only catch is that ocassionally we would have a session hang. We would have to restart the session on the server. This is easy to do. You just highlight the terminal ID and select "restart". Here is a link.

http://www.psionteklogix.com/public.aspx?s=us&p=Products&pCat=268&pID=2399#

I would still do some of the other tests, but I know how that can go on forever. Make sure you are using the lastest wireless drivers on your clients. There have been tons of wireless driver updates. Old ones tend to have "issues".

Randy

[rsamuel708]

Randy, thanks for your time and detailed response. Been very helpful. I'll take a look at the link and see what they have to offer.

/rls

[spinnabs1]

I also work in a health care organization that uses CoWs. We ran into the similar problems. It's not your wireless. As stated above, many internal wireless NiCs have very flakey drivers and were never designed to hold a connection for long periods of time or effectively roam in an enterprise environment. Nor were they designed to be used for mission critical apps that concern people's lives.

Another factor is that certain software developers have taken great "liberties" in their interpretation of how data should be sent across a TCP/IP network. Many of them a simply use direct RPC calls to a database on a server. Others take old mainframe communications and wrap them in UDP. Neither of these methods is tolerant of packet loss or high latency. On a robust wired network, one can get away with this without much notice from the user. On a wireless network, where speeds and latency can fluctuate widely based on RF environment, these applications just break down.

Suggestions:

1. Only use Cisco cb21ag adapters. They are the most reliable and Cisco TAC support on them is great.

2. Use Citrix for the applications. Citrix is far more tolerant to wireless connection, since it is only providing an interface to the app which is running on a server.

Doing these 2 things has greatly improved our user experience.

Hope this helps