Author: Martin

When looking into the future it's good to know the past as you can learn a lot for making predictions.

Let's apply this wisdom to the 3G network technology we currently use: I first used HSDPA in a real network back in February 2007 with a HSDPA category 12 Sierrawireless card. At the time, 1.8 MBit/s was the latest and greatest. Since then, networks have been upgraded to category 6, which allows 3.6 MBit/s in theory, and many networks are now category 8 capable with theoretical top speeds of 7.2 MBit/s. Going to 7.2 MBit/s has mostly happened in 2009. But when do you think cat 8 made it to the 3GPP standards? Surely it must have been fairly recently!?

No, not at all, HSDPA category 8 was already specified way back in 2002 in Release 5 of the 3GPP standards. More specifically, category 8 we are using today was first mentioned in V5.1.0 of TS 25.306 of June 2002. That was 6 and a half years ago! These days, 3GPP is working on Release 9…! It looks like that release of the specification was worked on for quite some time as cat 12, which was used for the first devices that came on the market (see above) was only added in V5.2.0 of September 2002 and 3GPP has continued changing the document up until 2009.

I think HSDPA is not an exception but fits a general pattern. From standards to live network, things take around 5 years. UMTS itself is no exception. First specified in Release 99, I got my first 3G phone in December 2004. I was not a bleeding edge user but surely an early adopter. Again, about 5 years from standards to live network.

P.S.: Yes, I know that some operators have announced that they've already deployed HSPA+ with 21 or even 28 MBit/s. In practice however, it's only a couple of base stations in a few select towns.

If program is a web app and runs in a web browser it doesn't really matter what kind of OS you use, right? No, that's unfortunately not quite the case as I recently discovered with Ovi Maps.

One of the reasons I went through the pain of upgrading Ovi Maps on my N95 and the long wait to get my 2.5 GB of map data update on the mobile was to be able to synch locations and routes between the mobile and the PC. But when I tried to log into Ovi maps on my PC running Ubuntu I was greeted with a "sorry, Linux is not supported, please use a browser on the PC or the Mac". What!?

In the meantime, Nokia seems to have made an important step forward concerning cross platform compatibility and the main functionality, showing maps and synchronizing favorites now works with Firefox under Ubuntu Linux. Thanks very much for that Nokia! 3D landmark visualization and route calculation, however, still end up in that nasty "sorry, not supported" dialogue. 

Anyone aware of what kind of technology they are using that requires special OS platform support?

Here's a bit of an odd thought for the day: It first happened with Bluetooth not so long ago: With its data rate limited to 2-3 MBit/s, Bluetooth is no longer capable of forwarding data between let's say a PC and a phone at full HSDPA speeds offered today in networks. As reported here, I get more than 5 MBit/s with a HSDPA category 8 device in a live network.

With the most popular Wi-Fi variant currently used, i.e. 802.11g with a raw data rate of 54 MBit/s and a practical maximum throughput of around 20 MBit/s, similar things will happen once we go to HSPA+ with data rates of 21 and 28 MBit/s and beyond.

Sure there's 802.11n that is capable of much more but it requires several antennas and its unlikely that we'll see it in mobile devices with several antennas anytime soon. But then, the thought is mainly academical anyway these days. While I used to tether my PC and mobile phone quite a lot in the past I only resort to it seldomly these days. In most countries, an extra (prepaid) SIM card for the PC for wireless broadband has become so affordable that I'd rather spend a bit more money than to go through the hassle of tethering.

But still, the thought shows nicely how technology has progressed over the past few years, with a wide area network technology now at the brink of surpassing the speed of a short range wireless technology that was only a couple of years ago thought of as being super fast.

There we go, lots of people have asked me in the past few days about my opinion on the publication of the IMS One Voice Profile to bring voice services to LTE. The spec, created by AT&T, Orange, Telefonica, TeliaSonera, Verizon, Vodafone, Alcatel-Lucent, Ericsson, Nokia Siemens Networks, Samsung and Sony Ericsson is available here.

There's a strong political and a technical side to this, so let's look at them separately.

The Politics

One of the main problems is that there is no clear strategy of how to deliver voice over LTE, the main cash cow of mobile network operators. As a result, several solutions have been suggested and specified, each with advantages and drawbacks.

As the impressive list of supporters shows, many parties hope and believe that the IP Multimedia Subsystem will do the job. Unfortunately, the IMS is suffering from its own complexity and the ambition of the companies working on it to evolve pure voice to a multimedia offering. Due to the complexity, however, little to nothing has so far ended up in the hands of consumers. The industry has tried to narrow their focus a bit by specifying service profiles such as MMTel and Rich Communication Suite version 1 and version 2 but there are no indications that this has changed this situation.

With the IMS One Voice Profile, many of the IMS supporters have now agreed to throw even more of the complexity overboard and concentrate on voice only. And that's the astonishing political side of this document to me. No longer are the companies dreaming their multimedia dream, they seem to have come to realize that they need to focus on voice and make this work first. An impossible suggestion only a short time ago. But the pressure seems to be mounting.

The Technical Side

When looking at the spec it seems to be likely that most IMS infrastructure vendors can already do the signaling exchanges described in the document and client software for mobile devices should also be complying either already or shortly. So from a technical point of view this spec doesn't change the status quo a great deal. Integrating this into a final solution is going to be the first tricky thing where the industry has failed over many years. Unfortunately the spec doesn't help with this issue.

The second tricky thing is the handover to a 2G or 3G circuit switched channel once running out of LTE coverage. Two features are required for this. The first is Single Radio Voice Call Continuity, a mostly radio network centric feature to coordinate the handover process from packet to circuit with devices that can only communicate with one radio access technology at a time. In addition, the IMS needs to interact with the circuit switched Mobile Switching Center (MSC). Although not mentioned in the 'One Voice' profile, I assume the IMS Centralized Services feature is used for that. If you want to see something really complicated, go have a look.

Some might argue that handovers to a CS channel are not required at first but I think without it, users will simply not accept the service as it offers few benefits over VoIP services offered by Internet companies. In fact, I think handover to CS is the biggest asset operators have to compete with Internet companies in the voice domain!

Final Thoughts

Personally, I think it's a good idea to concentrate IMS implementation activities on the most important service, VOICE! I have to wonder a bit, however, why to go through all this complexity for voice only, as that can be had for LTE much cheaper, much simpler and likely also much faster with other approaches such as Volga. Many see Volga as an ugly duckling, dragging along 'legacy' equipment. But with this 'legacy' equipment (the MSC) being on an IP evolution path as well, I don't quite see it this way.

So, I wish the companies speaking in 'One Voice' a lot of luck (I like the naming twist!) because no matter which approach will prevail in the end, we need voice services for LTE with proper CS interworking and we need it sooner than later!

And one more thought: I can imagine, and I actually think it's quite likely, that there will be more than a single solution for Voice over LTE deployed in the future. Competition often helps to speed things up. The good news is, it should be fairly transparent for the user as interoperability is ensured via the 'legacy equipment'.

SFR has just told me in an unsolicited email advertisement that in case I go for their "generous" 3G USB stick offer, 100% of all computers are compatible. In the fine print, they say they have drivers for Windows and Macs. Hello, haven't you forgotten something? Yes, I am using Ubuntu Linux, I guess that's the 0% you've been missing… But good news for you, your stick looks like a Huawei E169 and that should run just fine under Ubuntu as well, there are not even drivers required for it…

I've been looking around a bit for a future replacement for my aging Nokia N95. One thing that definitely has to work on the new phone is OperaMini as I am often in situation an places without fast and affordable 3G Internet access. I've noticed that OperaMini is available for the Android platform so I gave it a try on one of the new Android devices.

The Good Stuff

The Mini implementation on Android is great! Pages are loaded in a flash and the touch interface works very well for following links or selecting a page to go to from the bookmarks. The browser also doesn't have to stand back when directly compared with the native Android browser. The kinetic scrolling is not as smooth as with the native browser but on the other hand, pages are loaded much faster due to the network side compression. Also, unlike with the native browser, I can go back several pages very quickly as those pages are still in the cache and thus do not trigger a reload. Another important point: Copying/pasting of links works in the same (clunky) way as on the N95 by bookmarking a page, selecting and copying the URL in the process, aborting the task and using the URL for example in the e-mail application. Not very elegant, but it works.

The "Not So Good" Stuff

The one thing I didn't like: Either Android is not fully multitasking or the amount of RAM was not sufficient as whenever I went to the home screen and started another application OperaMini was closed and I had to start from scratch again when going back. The program loads very quickly but the previous pages were no longer in the cache. That's a pity as it works much better on my current N95, where the browser stays in memory no matter how many other applications are open at the same time.

Here's an interesting piece of technical insight I gained this week when going through 3GPP TS 23.401 concerning tracking area updates that I haven't seen when I went through the spec for my SAE review posts back in February (part 1, part 2 and part 3):

In UMTS, location area and routing area udpates are only done when the mobile is in idle state, i.e. no physical link is established on the high speed shared-, dedicated- or forward access channel. This makes sense as in these states the RNC in the access network is aware of the location anyway and can report location changes to the core network when necessary. Only once the mobile goes to idle state and the mobile makes the decision to go to another cell on its own without reporting back, routing and location area updates come into play if the new cell is outside the current area.

In LTE, the corresponding procedure is called a tracking area update. The first difference to the LAU and RAU of UMTS is that the mobile can have a list of several valid tracking areas and an update only has to be made if the new cell is in a tracking area that is not part of that list. So far so good. TS 23.401 chapter 5.3.3.0 says, however, that a tracking area update is made in both idle and connected state. Quite a surprise to me so I wondered why an update is necessary in the connected state!?

The answer to that question can be found in the message sequence charts for handovers. For example: during an X2 handover, which is directly negotiated between two base stations, the Mobility Management Entity (MME) in core network is only informed of the handover after it has taken place. Also, there's no direct communication between the MME and the mobile device during the handover procedure. That means that in case the new cell is in a new tracking area, the mobile has to update its tracking area list as that information was not contained in the handover messaging.

From a logical point of view that also makes sense. Traking areas are administered by the core network (by the Non Access Stratum) while handovers are performed by the access network. Also, the signaling does not interrupt the user data transfer so there are no side effects of performing this procedure in connected mode and while transferring data.

More LTE technical tidbits this week also over at Wired n' Wireless.

I know I won't get a real good answer for this one but I was just wondering of how much in the current set of 3GPP specs is no longer used at all anymore and, even more interesting, how many features and options specified over many years never made it to real networks!? With tons of features specified in each new release and only a few really used, I assume it should be a sizable percentage.

Why I care? Well, when reading the specs it's often not only difficult to interpret what is written but also if what you are just trying to figure out already is or will be used on day. Is this the price to pay for having one system to which (almost) everyone contributes to? What do you think?

I've recently had a chat with a friend on different 3G price models and I thought I'd write down a little overview to document the diversity of the tariff landscape in Europe today:

Let's start with examples from Germany: Here, a popular post-paid model is a fair use all you can eat plan with a volume cap, for example 5 GB, after which the bandwidth is throttled down to 64 kbit/s for the rest of the month. While staying within the bucket, speed is only limited by the device, network capability and radio conditions. Prices for such plans range between €30 and €40. Other volume caps also exist.

In the pre-paid sector, there are many offers for small screen devices billed per MB. Prices range between 20 to 40 euro cents per MB. Great for low to medium use with OperaMini and e-mail without attachment download. Some operators are also offering prepaid plans for notebooks with volume caps of a couple of hundred MB to a couple of GB for prices anywhere between €20 and €40. Vodafone and others have offers based on time, for example 24h access for €5 and a week for €10 with a volume cap at 1GB. If you dig a bit deeper the weekly package can also be had from a reseller for €6.99.

Finland: Here, Saunalathi Saunalahti offers unlimited bundles and charges based on maximum throughput. Prices range from €9.80 with a speed cap of 384 kbit/s up to €34.90 for a throughput of up to 5 MBit/s Gbit/s.

Austria: The el dorado land when it comes to mobile. Drei (Hutchison 3) sells 15 gigabytes a month for €15on a postpaid contract. Prepaid contracts are available as well, like for example those of Mobilkom and One, where €20 buy one gigabyte that can be used over 12 months. Maybe not very attractive from a price per GB point of view but for occasional users it's an unbeatable monthly price.

France: Here, clocks are still ticking differently compared to pretty much the rest of Europe. Orange for example offers 1 GB of traffic on a post-paid basis for €39.90 after which the bandwidth is throttled. 4 GB are offered for €79.90. Prepaid packages are only available on a time basis. 20 minutes go away for €3, an hour can be had for €8, six hours cost €25 and if you want to be connected for 12 hours over the duration of one month, you have to invest a staggering €35. Nothing really for always on connectivity fans.

Feel free to add to the list if you know of yet another variation.