Category: Uncategorized

Yes, app stores is where most people get their applications for their smartphones today. While this is convenient, simple and offers a way to earn money I'd argue it's not the 'natural' state of things. I'd never buy a PC, notebook, netbook or any other device where I can only download programs from a single store that is controled by a single entity with its own agenda. So why should I limit myself to that for a mobile device (think smartphone, tablet, etc.)?

This became quite apparent from a technial point of view to me when I recently tried to download something from an app store and couldn't due to some strange error that persisted for quiet a while. Well, at least I could download my most favorite apps (web browser and email client) from the web pages of the developers and thus bypass the store and the problem. A single point of failure, always a bad thing.

Recently I was in a hotel that had dedicated indoor cellular 3G coverage on the lower floors. Dedicated in this case meant that one mobile network operator installed indoor coverage with antennas distributed throughout the hotel. So I would say that most foreign visitors sooner or later landed on just that network as the other networks had only weak or no coverage at all. And despite roaming prices having come down in recent years I think calls from foreigners are still highly lucrative. So I wonder who paid whom for the indoor coverage? Did the hotel pay the network operator so guests have reception in all places where outdoor coverage is weak or is the mobile network operator paying the hotel for the opportunity to get (more or less) exclusive access to foreign visitors? I'd speculate that it's the later but that's just a guess on my side. In any case, good cooperation from both sides to make the customer happy.

One of the biggest assets mobile network operators have is the ability to handover voice calls seamlessly between different radio access technologies. If the calls starts in a UMTS network and the user leaves the coverage area of the 3G network, the call is handed over to the GSM network without the user noticing it. The reverse direction from 2G to 3G is also standardized but I have yet to observe any network actually doing it during an ongoing call. It could actually be quite useful so background data transfers such as email reception, facebook updates, etc. can continue during a voice call, something that is usually not possible unless the network supports GSM DTM (Dual Transfer Mode).

Anyway, things get a bit complicated in the LTE domain. First, there is no single Voice over LTE solution clearly dominating today, probably due to the lack of networks and devices. But let's say, for arguments sake, that we'll get there one day. How do you hand over a Voice over IP call to GSM once the user runs out of the LTE coverage area. The solution is Single Radio Voice Call Continuity, or SR-VCC for short, which has been specified some time ago in 3GPP TS 23.216. The procedure is voice technology agnostic so it can be used by IMS, VoLTE (an IMS implementation) and also VoLGA.

But once you are there, how do you get back to LTE or UTMS during the call? Well, not at all so far. However, there's a study item currently worked on in 3GPP Release 10 in TR 23.885 that gives a number of options of how reverse SR-VCC could be implemented. How interesting! I'm tempted to read it but I guess I'll just hold off until I see the first (forward) SR-VCC implementation used in a real the network. Have fun putting it into a TS until then 🙂

Have you ever tried the following: While sitting in a train, talk to someone standing outside through the window over a mobile phone.

It's interesting to experience the voice delay which isn't very big, I would say in the order of 250 milliseconds, but quite 'visible' as the lip movement of the person outside and the speech path are not quite synchronous anymore. In a mobile phone call where you don't see the other party this delay usually goes fully unnoticed unless you call someone on the other side of the planet and the delay becomes so long that there are odd silence periods and people start talking simultaneously.

The second interesting effect that can be observed is noise supression. As you know exactly how the background noise sounds outside, its interesting to hear if and how well the mobile outside surpresses the background noise and what effect that has to the talker's voice.

I haven't tethered my mobile phone with my netbook for Internet access for quite some time now for a number of reasons. One of them is that in the countries I usually stay, cheap prepaid options for a couple of hundred megabytes or gigabytes per month are available in the 10 to 20 euro price range. As a result I usually buy a SIM card that I then only use with a 3G dongle. With roaming prices capped in Europe I then mostly use my home SIM card for telephony and small screen web browsing.

But leaving that scenario asside, tethering is still worth at least 120 euros a year (based on 10 euros a month) if you can use the data contract with your phone/smartphone SIM instead of buying a separate 3G dongle and prepaid/contract SIM with it. I'm sure that still appeals to many people.

One of my 'must haves' from a mobile device in this regard is Linux/Ubuntu support for tethering. To my delight, even the latest Nokia models such as the N8 are still detected as 'modems' in Ubuntu (10.04 Lucid in my case) without any need for additional drivers. Very good!

I have noticed that espeically Android phones are used under windows as "virtual network card" but I never tried them under Ubuntu. Has anybody tried that and can leave some feedback here as to if/how that works?

Back in April I wrote a post on the dangers of NOT using a VPN over public Wi-Fi hotspots. As data is not encrypted, anyone in range using a network tracing tool on a notebook or other devcie can tap into the data traffic of the hotspot and filter out email passwords from non-encrypted POP and SMTP connections and session cookies e.g. from social networking sites (think Facebook, Twitter, …) that are only using non-encrypted http connections. While email passwords are straight forward to be used, things are a bit more tricky with the session cookies. But nothing a willy hacker with a bit of background knowledge couldn't overcome. Agreed, it takes a bit of effort which has so far probably prevented this sort of identity stealing from taking off so far.

But now cookie stealing in unencrypted public Wi-Fi hotspot seems to have become almost trivial with a Firefox plugin called FireSheep. It requires the Winpcap network driver to be installed, the same that is also used by programs such as Wireshark for network tracing. This way FireSheep can intercept all data traffic in a public hotspot and with some processing of the intercepted data, all computers used in the hotspot are shown to the user. As soon as someone with that computer accesses a service only using http, cookies are extracted and the computer running FireSheep can now be used to impersonate the other user with a single click on an icon in the browser. This is really scarry as it doesn't take a lot of effort or knowledge to install FireSheep and Winpcap. When I checked, the software was already downloaded 600 000 times! So I wonder when the first victim stories will appear. How far this will spread probably depends on the precentage of Wi-Fi adapters FireSheep can set into promiscuous mode so all packets are delivered to higher layers of the protocol stack.

Let's be clear, FireSheep does not exploit weaknesses in the browser or the OS that could be fixed. No, FireSheep exploits the intended design of public hotspots, i.e. to send data without any protection. But there's an easy fix: Use secure SMTP and POP (available from most email providers today) and make sure to only use web based services that offer https (still not done by many web sites today). If and when victim stories pop up I wonder how long it will take popular sites to switch over to https!?

On a further note, have a look at Dean Bubley's blog, he's got some interesting thoughts how this "click and shoot" hacking method might influence future 3G offload technology. Especially in that area, automatically established VPN tunnels as part of a Wi-Fi offloading solution would fix the issue for good. For the ordinary use of public Wi-Fi's, however, most users will probably still not care, know, be willing or capable of using a VPN solution. So for that scenario, https is likely to be the best defense.

Back in summer this year I ran a post on UMTS state switching and Fast Dormancy evolution to highlight the challenge current mobile devices have with battery consumption due to applications running in the background that access the Internet periodically. A major part of the current solution to the issue is a functionality referred to as "Fast Dormancy" which saves battery capacity by setting the radio link into Idle state quickly. This comes at the expense of a longer delay once data has to be exchanged again with the network and an increased signaling load in the network.

The fix for both downsides comes with the introduction of a new parameter in the Signaling Connection Release Indication message in 3GPP Release 8. With this parameter, the radio connection is not put into the Idle state but instead in the Cell-PCH state which is similar but doesn't have the afore mentioned downsides. Have a look at this post for a more detailed explanation. Usually, standards changes take years before they end up in real networks. This one, however, is quite simple to implement and there is real demand for it today. Now there are first indications from NSN, a vendor for 3G infrastructure, that they have implemented it and have run some first tests in a lab together with Qualcomm, one of the companies producing 3G radio chips.

Good stuff, let's see how quickly this is pushed out to real networks and real devices.

Right after 'open' and 'unlimited' the most mis-used word or acronym in the wireless industry is 4G. HSPA+ is not 4G, LTE is not 4G and Wi-MAX most definitely is not 4G either as they are all part of the IMT-2000 family, which is 3G. Call them 3.5G, 3.9G, 3G+, 3.999G, whatever, but 4G is not correct.

But now finally the International Telecommunication Union (ITU) has named the first network technology that will be part of IMT-Advanced, or, in other words, the first 4G technology. And this is 3GPP Release 10 LTE, also known as LTE-Advanced or LTE-A for short. Current deployments and activities revolve around 3GPP Release 8 LTE, which, once again, is not 4G 🙂 LTE-A is quite a number of years out and how realistic 1.2 GBit/s device classes will be in a couple of years is anyones best guess at the moment. But it's 4G 🙂

It's probably not the first conference it was done but the Forum Oxford Future Tech conference was the first that I attended that made use of it: In addition to the presentations, the Twitter feed for the conference was also displayed at the front for everyone to see and contribute. And it was heavily used by me and others to comment on the presentations and to bring further ideas into the ring. I really enjoyed that. Last year, when people twittered during the conference and it was not shown it felt more of a second layer running independently from the the event itself. By bringing it out in the open the virtual dimension and physical dimension was nicely combined. In other words, a good idea 🙂

When recently talking to someone about the apps he's using on his mobile device and which social networks he is active in he noted that he likes Facebook a lot but the app for it on his mobile device is so power hungry, he doesn't dare to let it run in the background because his battery will go flat in a matter of hours. That tells me that he probably gets a lot of updates that are then immediately pushed down to the mobile, which in turn requies the radio to be switched on quite often. There we go, a natural barrier hit.

So what is needed in this case is that the apps becomes more situational aware. When the display backlight is switched off and the phone is locked there's no need for updates to be pushed continuously and the app could inform the backend server so status info is collected and stored until the user actually checks for updates again. I don't think that would be difficult to do. And surely, network operators would be happy about it as well as it reduces the signaling load on the network.