Category: Uncategorized

This week I was in Malta for a couple of days and as usual I was looking for some affordable local tariffs for wireless Internet access with one of the 3G operators on the island.

Offers from both Vodafone and Go Mobile sounded promising and reception in the hotel room was equally good so I let chance decide which one to take. Vodafone SIMs were sold out in two tourist shops I tried but I was able to get a Go Mobile SIM card with the second one. No registration, they are just sold over the counter for 10 euros and an extra 10 euros for some credit to activate their internet offer for 4 euros for 10 days, 350 MB max. This should do for the vacation. So far so good. Activation of the SIM card was straight forward by just calling a short code and activation of the Internet offer was done quickly as well by sending an SMS with the name of the offer which was confirmed within the minute. What didn't quite work as expected was that the line was not provisioned for packet access, i.e. the GPRS attach was always rejected. Strange, you can book an Internet offer but GPRS services are not activated at the same time?

So I first called the customer help and top-up line (123), or at least tried to, as whenever I pressed the option in the voice based menu for a customer representative the call was released. Real good customer service… After the third time I gave the leaflet that came with the SIM card a closer look and found another direct number for the customer help line. Fortunately there was an English help-desk so I explained the issue without getting too technical. The support person insisted to send me an SMS to configure my phone despite me explaining several times that it's not the phone but the network that needs to be configured. I gave up in the end hoping that the SMS configuration would perhaps also trigger the corresponding network parameters for my line to be set up. Unfortunately it didn't. I was almost prepared to give up and search for a Vodafone SIM but wasting 20 Euros is a bit much. So I decided to give them a final call. I ended up with the same support person as earlier, explained to him the issue again and this time gave him the full technical issue –> "Configure my line in the HLR for GPRS services". I was put on hold for a couple of minutes so I guess he spoke to a network technician. When he came back he told me that things should be working now so I restarted the phone and indeed, the GPRS attach went through this time.

Fine, I had Internet access now but this raised a number of questions:

• Why were packet services not activated in the first place?
• Why weren't they activated when I bought the Internet bundle via SMS?
• Why was the call to the help line not working via the general number?
• Why did it take two calls to get things working despite a precise error description?

Without technical background knowledge I don't think I would have gotten it to work. Also I was quite glad I had a Symbian phone with me because here one can see on the idle screen why things weren't working (the GPRS attach already failed). On other devices based on Android, for example, this information can't be seen at all.

So, Go Mobile, if you read this, have a look at your back-end procedures to see how they can be streamlined to make things a bit smoother. Oh and yes, by the way, make the default APN work so people don't have to guess the APN for general Internet access after the GPRS attach works (which is 'rtgsurfing' by the way).

 

Have a look at the picture on the left that I recently re-discovered. It's back from 2001 and shows the mobile devices I was using at the time. A Siemens S25 GSM mobile, no GPRS yet and a Palm III. Internet connectivity for email and some very very basic black and white web browsing over and infrared link and a circuit switched data connection (9.6 or 14.4 kbit/s) to an analog fixed line modem of an internet service provider. And that was only 10 years ago! Interesting to compare that to the gigahertz powered processors we have in mobile devices now, gigabytes of Flash RAM and display resolutions equaling that of desktop PCs of the time.

This might help to understand how people where once excited about 384 kbit/s wireless connections over the future UMTS system. Look at it also from this angle next time somebody says that UMTS was a mis-design before HSDPA was put on top of it.

Next in line on my Android exploration path is how Wi-Fi is integrated into the system and how the OS switches between 3G and Wi-Fi use automatically. The implementation in fact is straight forward. If a Wi-Fi network is detected for which security details are available, Android automatically changes from 3G to Wi-Fi use. For running applications that means that their current TCP/UDP context is broken and that they have to reestablish contact with the server. For my most often used applications, Opera Mini and Profimail, that works quite well as most of the time they don't transfer data and therefore the switch usually happens when they can live with an interruption anyway. If I remember well, I was once told that the iPhone performs a 3G/Wi-Fi switch in the same way.

But what happens when there is an ongoing data transmission while the bearer is switched? I gave it a try with a podcast application that can also stream a podcast from a server. As expected the OS did not care that there was an ongoing transmission and the stream download was interrupted. The streaming application presented an error and had to be restarted manually. Not so nice.

Symbian on the other hand uses a different algorithm that prevents such behavior. Different networks can be grouped and priorities can be given for each network in the group. Individual applications can then either use the networks of the default group or can be assigned another group. For my podcasting application for example, I use a "home" group that only contains my private Wi-Fi network. This ensures that I don't use the 3G connection for large downloads by accident. I've also configured the SIP telephony client to the "home" group so it automatically starts up once the home Wi-Fi is detected. Changes between the networks in a group are not allowed while at least one application is running that uses the network group. This way the loss of TCP/UDP contexts is prevented.

In practice I think few people will use all the possibilities offered by the more complex Symbian implementation. They will most likely only have a single group with all known networks part of it. To prevent TCP/UDP context loss, Wi-Fi is only used when all applications are closed. That might have been o.k. a couple of years ago when applications were closed after use but with email programs and web browsers running in the background all the time now, it's not ideal anymore. But neither is a drop of the TCP/UDP context as in the Android implementation.

There is of course a remedy by using one form or another of mobile-IP to rescue the IP address when switching between access networks. There are several different ways to do this, unfortunately, which is likely going to hinder implementation and use in the foreseeable future. But sometimes a simple implementation trumps over more complicated ones if the drawbacks are acceptable.

Have you noticed that in the mobile domain the use (not necessarily the popularity) of operating systems from different companies is exactly the reverse order as on the desktop!? Leaving RIM and Symbian aside for the moment as these OSes are not present on the desktop the order is as follows:

• Linux, known as Android from Google
• iOS from Apple
• Windows Phone 7 from Microsoft (with a huge gap to the second one)

And from what can be told today, I don't think this order is going to change anytime soon, neither in mobile nor the reverse order on the desktop.

One important point when wanting to circumvent the Google cloud is how to import contact and calendar information to Android and how to back up the content. For contacts there are quite a number of options. The simplest on without any additional programs required works as follows:

Import Contacts

• On Symbian, mark all contacts and export. For each contact a single file is created
• In the file manager mark all created files and send them via Bluetooth to the Android device
• On Android, each contact can then be exported by clicking on it. This, however, is a bit cumbersome, especially if there are many contacts to import (like in my case)

To speed things up one interesting tip found here recommends to concatenate all contact files into a single large file and import that to Android:

1. Copy all your vcf files [exported from Symbian] into one directory
2. Open Windows command prompt.
3. Enter the following DOS command: copy *.vcf all.vcf
[4. Send via Bluetooth to the Android device and import all with one click]

Backing-Up Contacts

In the contacts application select "Menu – Import/Export – Send namecard via". Click on "select all" and then select Bluetooth to transfer all contacts in a single .vcf file. Works well and all contact data is available in readable form in the file. I then deleted the contact information on the Android device and used this single file to import the entries again to verify the process in the opposite direction and also step 4 from the tip above.

Other Import/Backup Options

A web search revealed quite a number of third party applications including one that synchronizes the Android contact data base with an address book in Thunderbird. An interesting solution but I haven't tried it myself yet. Also, a closer look at Funambol might be worthwhile as it synchronizes calendars with Thunderbird as well.

Last year, first reports about Wi-Fi Direct went through the press, a technology to exchange large amounts of data quickly and easily between devices over Wi-Fi. So far, Bluetooth is used for the job but with it's limited transfer speeds of around 2 MBit/s on the application layer, it starts having difficulties with larger files no common due to increase in megapixels and general quality of images. At this year's MWC in Barcelona I have seen Samsung advertising their Wi-Fi Direct implementation for first devices (see pictures on the left). A quick web search revealed that LG is also working on / releasing Wi-Fi Direct capable devices.

So what's the difference between normal Wi-Fi based networks and Wi-Fi Direct? Normal Wi-Fi networks have a central Access Point (AP) and a device joining a network for the first time usually asks the user for password that is then used for authentication and encryption. This is a bit cumbersome if the connection between two Wi-Fi devices is only required temporarily. This is where Wi-Fi Direct comes in as it allows a hassle free connection establishment between two devices without requiring an external access point or the entry of a long password. Here's a line from the Wikipedia entry on the topic that describes it pretty well:

"Wi-Fi Direct essentially embeds a software access point, or "soft AP", into any device that wishes to support [Wi-Fi] Direct. The soft AP provides a version of Wi-Fi Protected Setup with its push-button or PIN based setup."

 

Coming back to my roaming requirements for this part of the story, it's not only important that the web browser and the e-mail application require as little data as possible but also that Android itself is not chatting with the world and thus incurring cost. So to see what Android does, I installed "3G Watchdog" and let the mobile run overnight with Opera Mini being executed but the e-mail program shut down. Good news here as well. As I don't have any active widgets, instant messengers or other programs running that could exchange data in the background, the watchdog counter only recorded around 4 kilobytes of data exchanged. It would be interesting of just what those 4 kilobytes where but I'll leave it at that for the moment. From a roaming perspective that's quite acceptable. In other words, Android has passed my roaming data test as well.

When you are a bit bored next time you are in a public place have a look around to see what kinds of mobile devices which people use today. A couple of years ago, smartphones were early adopter toys and mobile Internet practically unknown and undesired by the general public. Today, the picture is totally different. I have to admit that I am still surprised when I see people who are likely to be in their 60s with an iPhone browsing the web. But it's by far not an exception anymore. That also means that the target audience for smartphones has significantly shifted from only half a decade ago. Not a homogeneous early adopter audience anymore but anyone from student to retiree has now become a 'real' customer in this segment.

Recently, I discovered Internet radio streaming on my mobile. There aren't many options but it's easy to use and after one has spent some time to find the radio stations that provide good content audio quality and save them as favorites it's "click & go" fun. Using it in a stationary way works well, but how about streaming while sitting in the tram or moving through the city? Will the program have enough data buffered for short outages?

So I tested it on a route from which I know that there is continuous and good 3G coverage (no use trying it on the train I take almost daily where I know 3G coverage is patchy at times). And yes, in areas with good 3G coverage, streaming worked well and during the 20 minutes I tried I encountered no major glitches. The only downside is that the mobile gets a bit warm over time and it takes a heavy tool on the battery. So in other words, continuous radio streaming requires two things:

• A good 3G network on the route
• A charger at the destination.

The issue of high power consumption is unlikely to be fixed anytime soon as 3G chips tend to get faster but not significantly more power efficient. Therefore I don't think we will see hordes of people running around streaming their favorite music instead of listening to "bottled" music anytime soon. Also, the network coverage I used for the test was exceptional. In most moving use cases, you end up sooner or later in places where no 3G network is available and your audio stream comes to a sudden halt. That completely kills the experience.

Don't get me wrong, I love Internet radio and often have a stream running on my PC while at home. But in a fully mobile environment I am a bit skeptical that there will be a take-up beyond occasional listening.

After giving you an intro of what I'm after in this series in part 1, let's get to the details. There are two main applications I need on my mobile phone:

Web Browser

First, I need a browser that is both fast and resource efficient as I travel a lot and roaming charges, especially oversees, are an ongoing issue. On Symbian, I have used Opera Mini for many years now as it's an excellent browser and uses a compression server that minimizes the amount of data transferred. Luckily, it's available on Android as well and works identical to the Symbian version.

I've also tried out Opera Mini Android / Symbian side by side while traveling on the train to see if there are differences between the two versions when the connection is constantly switched between GSM and UMTS and if there is a difference recovering from network outages. I pretty much got the same stable behavior on both the N8 and the Galaxy S. So that fixes web access.

E-Mail

The second most important mobile application for me is e-mail. Needless to say that I have special requirements here, too. Especially for roaming I need an email application that only downloads the first couple of kilobytes of the email. For reasons explained in part 1, gmail is out of the question and the default SMTP/POP/IMAP email client alternative doesn't seem to support my download limit requirement. But fortunately there are two alternatives. The first is the independently developed K-9 email program with lots of flexibility. And the second is Profimail, an email program I have been using for years on Symbian. Being ultra configurable, the Android version behaves and looks just like the Symbian original. As Profimail supports configuration export and import, I was up and running on Android in a few seconds by forwarding the configuration including all email settings via Bluetooth. I tested the program over several days and it worked very well. The only thing I am missing is a pulsating indicator light that shows me that new messages have arrived when the screen is switched off.