Mobile Unified Communications – Part 3: The Experience

Here are the results of the Mobile Unified Communications testing project.

Assuming you've read Part 1 and Part 2 of this series, and you really need to before proceeding here, the following is what we discovered during the MUC testing project.

Testing was performed in the following major venues: Munich, Germany (the airport only); Oslo, Norway (various locations - and the same with all following locations except the last one); Rostock, Germany; Berlin, Germany; Tallinn, Estonia, St. Petersburg, Russia; Helsinki, Finland, Stockholm, Sweden; Copenhagen, Denmark, and Frankfurt, Germany (again, the airport only). Munich and Frankfurt airports offer 30 minutes of free Wi-Fi on their T-Mobile network, and both voice and data worked great here.

I had good connectivity almost everywhere in the downtown Oslo area, and absolutely no issues with data or voice anywhere I could connect. There was only one open network that I couldn't get to work at all, but such is a common problem - either the iPhone reports that it can't connect, or one gets connected with zero throughput. Voice quality was uniformly excellent on every call, covering about 60 minutes altogether. Wi-Fi service at the hotel was both free and excellent.

Berlin was another story. I found very few Wi-Fi networks at all, and (that common problem again) the open ones that I did find allowed me to connect but refused to forward any data. This was really surprising and universal in the downtown area, both East and West. No luck as well in Rostock, where the ship docked, or at any of the stops along the autobahn connecting Rostock and Berlin. Cellular was not a problem, however, other than, as previously noted, being wondrously expensive.

Results in Tallinn were similar to Berlin, but not a total meltdown. Finding a Wi-Fi network took some doing, but the Port of Tallinn eventually worked, although sporadically. The bus that transferred us to downtown had Wi-Fi that was much better, and I had limited voice connectivity during that brief ride. As was noted in Part 2, the client seemed to have problems in sending DTMF tones to control voice mail, and consequently I wasn't sure how many messages were left unheard nor if those intended for deletion did in fact hit the bit bucket. As for e-mail, I think I was up to date, but the Yahoo Mail client for the iPhone seemed to misbehave - some messages were listed as duplicated, and a sent message seemed to go through but did not immediately show up in the Sent folder. Yahoo still has not cleaned up its software act, practicing the very best of Microsoft's proven techniques (for irritating users, anyway) for as long as I can remember. Again, no issues with 3G data or cellular voice.

Connectivity in St. Petersburg was great - but only because the tour bus I was on for two days had a Wi-Fi/cellular router. While many on the bus reported issues ("is the Wi-Fi working?" was heard more often than any other question, perhaps a sad commentary when one is surrounded by so much that is unusual, cultural, and historic), I had no issues at all. The Web and e-mail worked as expected (perhaps a bit slow at times, but that, too, was expected), and we did have one dropped call, also no big deal with such a configuration and motion through a city. I was surprised, though, that I found basically no open APs in St. Petersburg at all.  More on this in the Cultural Notes blog entry (Part 4 of this series, to follow).

Helsinki greeted us with several open Wi-Fi networks, and e-mail worked immediately. Unfortunately, Voiper would not connect to our server on any network. So, it was time to really diagnose the problem. Again, I didn't have my usual complement of tools, but I did download two from the iTunes Store: Fing to do basic discovery, and iNetTools for ping and traceroute. As I suspected, pinging just about anything resulted in timeouts, and the results for traceroute were identical. So, either the AP was overloaded with client activity (almost certainly the case in the morning, but likely not so much in the middle of the day when everyone but me - just kidding here - was out), or, more likely, backhaul was severely under-provisioned, and/or this may have been an instance of the blocked IP ranges noted in Part 2 of this series rearing their ugly head. I see under-provisioning, though, all the time, the result of obsolete site-survey-centric thinking that optimizes for coverage over capacity. Of course, one might argue that this is a case of what-do-you-expect-for-free, and that's fair. Anyway - bottom line, no voice via Wi-Fi in Finland.

Stockholm, Sweden, was a qualified failure. There's Wi-Fi in the port, with a posted password, but it was so overloaded I could get connected only on rare occasions, and then basically got nothing through until the connection was finally dropped. It was, however, fun to commune with fellow Wi-Fi seekers in port, on Deck 7, dockside - these folks knew the drill. I did get connected for brief periods, enough to download e-mail, via passing Wi-Fi-equipped tour busses, and even got voice mail to kind of sporadically ring, but wasn't connected long enough for it to answer. There were few open APs that I saw in the many parts of the city I visited, and none of these yielded any connectivity.

I wonder whatever happened with Fon, Boingo, iPass, and all the others - not that I could pay for Wi-Fi given the ground rules of this test, but I saw no real Wi-Fi industry anywhere I went. This was unexpected - again, Wi-Fi has the potential to offer real performance in terms of both throughput and capacity, to say nothing of voice, and cellular offload is going to happen, as it must. On to Copenhagen, but my expectations were at that point quite low.

As it turns out, no need for those low expectations: the Wi-Fi at the hotel in Copenhagen was great. I also managed to get connected on a couple of other open networks elsewhere in the city, and everything worked just fine there as well.

Frankfurt Airport was just like Munich - no issues, and the same terms. By the way, the 30-minute limit seems to be tied to a given e-mail address, not, as I would suspect, the MAC address of one's Wi-Fi adapter. So one could conceivably get plenty of connectivity during a relatively long layover with all of the voice and data one could need or want.

That's all for now. I'm at Interop this week and I expect a few announcements of note there, which I'll review as appropriate. The next entry in this series is the aforementioned Cultural Notes, a travelogue of sorts, and Part 5 will contain a few conclusions and other key points. Stay tuned...

To comment on this article and other Network World content, visit our Facebook page or our Twitter stream.
Must read: Hidden Cause of Slow Internet and how to fix it
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.