Category: Uncategorized

While doing a bit of background research on the amount of wireless spectrum available and used in the US today (more on that in a future post) I had a closer look at the AWS band. The AWS band is mostly used in North America today and encompasses a bandwidth of 45 MHz in the 1700 MHz frequency range for uplink transmission and another 45 MHz for downlink transmission in the 2100 MHz range.

Here's a link that shows who owns how much of that spectrum in the US. T-Mobile US seems to be the only active user today for its UMTS services but pretty much every one else including Verizon and I suppose AT&T (through Cingular) have a chunk as well and might use it in the future for UMTS or LTE services.

But like T-Mobile US, whoever starts using that band will require specific devices supporting that band. For T-Mobile US things have improved a bit in the last year or so with quite a few devices supporting the band now, including all new Symbian3 devices that are even pentaband UMTS capable, i.e. supporting all three US bands and the two major bands used in the rest of the world.

So in other words, most parts of the AWS band is still unused in the US at the moment.

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.