Category: Uncategorized

The air interface is the scarcest resource of a mobile network and the industry is therefore not only looking to improve peak data rates but also to improve efficiency under everyday conditions. Voice calls are and probably will remain for quite some time to come the most popular mobile service so reducing the overall amount of spectrum required for it to have more room for bandwidth intensive applications is an appealing goal.

Holma and Toskala's book on LTE I reviewed recently has an interesting analysis of this topic. The results sound quite amazing to me so I thought I'd share them with you. In their chapter on VoIP they compare the air interface efficiency of GSM, UMTS, HSPA and LTE and here are some of the highlights:

Voice over GSM, UMTS and HSPA is circuit switched in nature in their study. Therefore they have the advantage that there is little overhead incurred by the different layers of the IP protocol stack. GSM voice capacity was calculated for the Enhanced Full Rate (EFR) and Adaptive Multi Rate (AMR) codecs mostly used in today's GSM network. It's not straight forward to calculate how many voice calls fit into 1 MHz, as adjacent GSM base stations have to use different channels to avoid interference. Due to the modulation, directly adjacent channels can't be used and interference is countered by using hopping carriers, i.e. the transmission frequency is changed for each frame. Taking all these and other things into account they come to the conclusion that there can be around 4 EFR calls per MHz or 8 AMR calls. Quite a difference already.

The same calculation for UMTS and HSPA is probably a bit simpler as all base stations use the same frequency. Interference from neighboring base stations are part of the design and limit the available bandwidth in neighboring cells.  The more load in a cell, the more interference in neighboring cells and the less capacity there. With a simulation of a real life scenario Homa and Toskala estimate the voice capacity per MHz of UMTS of around 12 calls and of HSPA of around 24 (both AMR 12.2). Note that voice over HSPA is not yet deployed in life networks as it's a relatively new feature. For details have a look here.

And now over to LTE. Like for the other technologies, the authors have taken lots of layer 1, 2 and 3 mechanisms into account like for example what's the efficiency of using a 1 ms TTI for a single 20 ms voice frame,  how buffering several voice packets and then sending them together impacts performance and latency, different voice codecs, dynamic vs. persistent scheduling, use of signaling resources, etc. etc. The surprising result, at least to me, is that voice capacity is even higher as for HSPA and they estimate it to be 50 parallel calls per MHz for AMR 12.2 and over 80 parallel calls per MHz with AMR 5.9.

Summary

The numbers are stunning and offer interesting opportunities in the future. According to these numbers LTE is 10 times more efficient to transport voice calls than the current GSM deployment. That is, of course, if the voice calls are controlled by the operator and all optimizations used for the calculation are put into the game. For over-the-top VoIP, that's hardly going to be the case.

I've been playing around a bit with some devices lately with 'full web browsers' (again). However, no matter how hard I try to convince myself that this is the way forward, I'm still drawn back to OperaMini on my N95. Especially when traveling to work each day by train, Opera Mini loads compressed web pages much faster than browsers that download the full pages, especially in spots where only 2G coverage is available. Also, navigating on pages with hardware keys by pressing number keys to scroll up and down is much faster than moving a finger over the touchscreen. It might not look as nice and it takes a bit to learn the key combinations but it is much more convenient and it only takes one hand to browse the web.

Interesting how within just about one year after the release of the first Android phone in Q3/2008, the list of companies that have launched or are close to launching an Android phone has gone far beyond just HTC. Here's an overview:

• HTC 
• LG
• Samsung
• Motorola
• Sony Ericsson
• Huawei
• Dell
• Acer (o.k. a netbook, but let's count them, too)

The list's probably not complete and there are likely also some smaller less known Asian manufacturers who are in the game as well. So except Nokia and Apple, all major manufacturers are now in the boat, most with a multi-OS strategy. That could kind of make the air a bit thin in the future for other open OSes such as Symbian and Maemo. I guess Google must be pretty pleased with the success of their platform so far.

I still remember that not so long ago, few would have believed such a rapid development was possible. That includes me.

The news web sites have it today (here, here and here) that NTT DoCoMo announced today that they plan to switch-off their 2G network in March 2011 and solely rely on their UMTS and LTE networks afterwards. Wow, a great step but they are likely to remain an exception for quite some time to come.

The reason behind that is that DoCoMo uses a 2G wireless technology that's pretty much incompatible with anything else in the rest of the world. In other words, they won't loose a lot of roaming charges with this move.

By switching-off their 2G network they'll significantly save money on two fronts: First, there's one network layer less to to keep running so that certainly saves a great deal of money. Second, they no longer need proprietary dual mode 2G/3G devices and can go forward with dual mode GSM/UMTS mobiles that are sold in the rest of the world (+ an additional frequency band, see below) or triple mode GSM/UMTS/LTE devices. And while we are at it, does anyone know if current devices are still dual mode or has DoCoMo phased this out already and just keeps the 2G network running for legacy devices?

And a final thought on this one for today: Looks like in Japan DoCoMo doesn't only use the 2.1 GHz band for 3G but also a band in the 800 MHz region (FOMA Plus) which is also used by their 2G PDC system. Here's some more details on this from a report on a Blackberry version for Japan. That report also indicates that the band is different from the 850 MHz band used in the Americas. It would be too simple otherwise… So once they switch off their 2G system, they can do further re-farming. Also a nice benefit.

When you walk through any town in Germany and many other countries these days and have a look at what's advertised in mobile phone stores, it's usually phones (naturally) and notebooks or netbooks with a 3G USB dongle for a reduced price. Some stores have now started to differentiate a bit and now advertise net-/notebooks with built in 3G connectivity. For most people it makes much more sense to have the 3G card inside, it just takes less space and you can't forget to take the dongle with you. But there are also some major disadvantages.

• A 3G USB dongle can be used with several computers and at least for me that counts for something.

• Also, it's easy to exchange the SIM card, which I do a lot when traveling. I expect, though, that most people won't care about this one.

• And then there's reception. In most parts of Europe, UMTS is still only on 2.1 GHz except for a few places with 900 MHz coverage. In other words, in-house is far from optimal in many places. So every now and then I am very happy about a USB stick solution that I can extend with a 2-3m USB extension cable and hang over a lamp or to place the 3G stick close to a window for better coverage and faster speeds.

• And then the stick can be used as the receiver for a 3G/Wifi bridge such as this one. Again, most people don't care but I like it a lot. When I travel alone, the stick is in the PC but then it's great to be able to share the connectivity when the need arises.

So do you think 3G USB sticks will mostly be integrated into netbooks and notebooks over the next couple of years or will the majority of network operators and users prefer an external solution?

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?