Category: Uncategorized

One of the most important Firefox plugins I use on the PC is Adblock Plus. Not only does it significantly reduce the blinking and flashing of overly obtrusive advertisement on web pages but it also accelerates download times. On mobile web browsers, however, a similarly easy to use functionality seems to be still a bit away.

For the iPhone, it looks like there are some programs available but only with a jailbreak. On Android some experimental software seems to exist and there is an app on Android market but it requires the user to change proxy settings manually.

Opera Mini on my phones automatically loads the mobile version of many of my favorite pages which have reduced advertising. A creative way to reduce over-obtrusive advertisement.

So what I am still missing is an easy to install add-on just like on the PC. It's about time, even if Google and Apple don't like it. But maybe I am overlooking something, so as always, feedback is welcome!

How about Windows Mobile, Maemo, the Palm Pre and other platforms?

There are two main advantages mobile network operators have when it comes to offering voice calls over LTE (and HSPA) compared to Internet based companies: Handover of an ongoing call to a 3G or 2G network, which I think is their biggest voice asset, and being able to ensure quality of service, in other words, the voice service can interact with the transport network and the base station to ensure the IP voice packets get precedence. But how is it done in practice?

The mechanism of choice for this in LTE is called a dedicated bearer. In HSPA, it's known as a secondary PDP context. Dedicated bearers / secondary PDP contexts are established when a service in the network requests a priorization of IP packets belonging to a specific media stream between two IP addresses and TCP/UDP ports. So far so good with the theory, but how could the functionality be used in practice?

The IMS One Voice Profile contains an interesting and quite precise answer for this:

An Unacknowledged Radio Bearer for Voice Packets

In chapter 7.3.1 the spec says that on the radio interface the following bearers are established during a voice call: SRB1 + SRB2 (those are signaling bearers to keep the radio connection alive), 4 Acknowledged Mode Data Radio Bearers (AM DRB) and 1 Unacknowledged Data Radio Bearer (UM DRB).

So what are they for? Chapter 7.3.3 gives further details: Acknowledged and unacknowledged mode refers to the layer 3 RLC protocol that can ensure that data that is somehow lost over the air interface is repeated. Repeating lost data (acknowledged mode) is the default RLC operating mode for user data in HSPA today and I expect that to be the same for LTE as well. For a voice data stream, however, it doesn't make sense to repeat lost data as the repeated voice packet would come too late to be useful. This is why an Unacknowledged Mode Data Radio Bearer (UM DRB) is used.

In other words: The voice service (in the network) sends a request to the transport network during the establishment of the voice call to create a dedicated bearer for IP packets being exchanged between two IP addresses and two UDP ports to be mapped to a radio bearer for which no RLC error correction is used. All other IP packets not matching the IP address and UDP port combination requested above are sent over an AM DRB without guarantees for latency and bandwidth.

Prior to 3GPP Release 8, resource reservation was the job of the mobile device. With LTE and 3GPP Release 8, this functionality has now moved to the network. The IMS One Voice Spec remains a bit sketchy on this particular point. The VoLGA Stage 2 specification, however, shows quite clearly how the dedicated bearer is established from inside the network in Figure 9.8.1.

Note that an extra dedicated bearer established for the voice call does not require an extra IP address for the mobile device. In fact, only a single IP address is used as it's the combination of the IP addresses and UDP ports that distinguishes the packets that go through the UM bearer from those that use an AM bearer. For the the application on top (e.g. an IMS client or a VoLGA client) all of this is transparent as the protocol stack below automatically decides which IP packet should be sent over which bearer.

Packet Loss Rate

To ensure that the packet loss in UM mode stays within reasonable limits, the radio transmission characteristics (power output, modulation, coding…) for the UM bearer is configured to ensure that the packet loss rate does not exceed 1%, a value that the voice codec can still tolerate.

Guaranteed Bit Rate

Chapter 7.3.4 of the One Voice Spec then goes on to add that the UM DRB for voice is configured with a guaranteed bit rate and that the network resources are permanently allocated to the user during the call. One of the possibilities to do that is for the base station to tell the mobile device that it can periodically send and receive data without looking for bandwidth assignments. That guarantees the bandwidth for the call and also saves the overhead of dynamic bandwidth assignments which are not needed as the bandwidth requirement is static.

Header Compression

The main thing that makes voice over IP very inefficient compared to traditional circuit switched transmission is the overhead from the IP headers of each packet. To this end, the spec requires that Robust Header Compression (RoHC) is used between the base station and the mobile device. I am not sure yet whether LTE vendors will use RoHC for all data streams or only for some such as dedicated bearers.

DRX

An important feature of the LTE air interface is discontinuous reception (DRX). It allows the UE to put its transceiver to sleep for the DRX period. This is especially important for voice sessions as the bandwidth required is so small that the time between two IP packets containing voice data is very long. Keeping the receiver constantly switched on would waste a lot of energy in the mobile device. So the spec requires DRX configuration while a voice call is ongoing. To be fair, I expect DRX to be used also for best effort transmissions, so it's not a feature that was only made for voice.

Summary

To the voice service on top of the protocol stack, all of this is pretty much transparent. It just requests QoS to be enabled for a data stream via a network interface and gives the network the required parameters (e.g. IP addresses, TCP/UDP ports, bandwidth requirement, etc.) and the rest is done by the transport network. To that end, network operators one day might even discover it as a service they could sell to companies offering Internet based (voice) services.

Earlier this week I ran a post on voice handover from LTE to GSM (or UMTS) and received an interesting comment from a reader who was of the opinion that there is not much benefit coming from such a handover. He said that instead, the industry should make LTE phones in the future that use GSM for voice and LTE for data.

At first I thought, yes, that's what CS fallback is all about, which nobody, me included, really wants. Personally, I don't like the approach because it significantly increases the already long call setup times and falling back to a legacy network for your bread and butter service is not how wireless technology should advance. But then I read the comment again and realized that the author suggested a devcie that could do GSM and LTE simultaneously. An interesting idea!

And it might even be possible as something similar already exists today! Multi SIM phones that have two transceiver units so both SIM cards can be active in different networks and on different frequency bands simultaneously. This shows that devices with two independent transceivers are practical. In the case of the dual transceiver LTE phone there could be one LTE/UMTS/GSM chain and one independent GSM chain that is only used for voice telephony. Both could work with the same SIM card as long as the GSM chain only communicates with the circuit switched GSM network. Should the LTE/UMTS/GSM chain have to fall back to UMTS or GSM, the GSM only chain could be deactivated in favor of a combined treatment of CS and PS. It would make things a lot easier for the network people.

But we are moving towards an IP only world both in the fixed and the wireless telecommunication domain and this approach doesn't fit into this picture. So I keep preferring an IP based voice solution for LTE which has a handover option to GSM and a single transceiver chain in the mobile device. However, I can very well accept that there are other opinions out there concerning this matter so thanks for the comment, it got me thinking!

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.