Category: Uncategorized

With the rising use of the mobile Internet, the amount of signaling required to set-up and maintain radio bearers is changing. While in pre-mobile Internet times, radio and core networks were mainly dealing with location updates and signaling due to SMS and voice calls, always-on smartphones are used quite differently.  Lets do a little comparison:

Someone who's only two applications that require network interaction are SMS messages and voice calls might have the following signaling pattern:

• 4 radio bearer setups a day for incoming SMS messages
• 4 radio bearer setups a day for outgoing SMS messages
• 2 outgoing voice calls (some with handovers, which increase signaling load)
• 2 incoming voice calls (some with handovers, which increase signaling load)
• 5 location updates a day (periodic and some triggered because the user as he moves)
• no routing area updates since the mobile is only attached to the circuit switched side of the network
• These numbers are obviously for someone who doesn't move a lot and who is, by today's definition, someone with a low usage. The young generation often sends and receives my more SMS messages a day.

Personally, my CS messaging load is a bit different. I send and receive fewer SMS messages as I mostly use e-mail for text messaging as my friends are distributed throughout the world and these exchanges are usually also not required to be had in real time. But I usually make and receive more than two calls. I try to minimize calls when moving as I find it impolite to talk on the phone while on a public transport and also prefer some privacy when calling.  But for the calls I do make while on public transport I am glad handovers exist.

But now lets go to the packet switched side and see how things are here:

• I am always-on and receive about 4 e-mails per hour. In other words, there are 4 signaling evens per hour or about 4 * 15 hours (per day) = 60 events per day for this application alone. That easily surpasses all my CS signaling
• While on public transportation I often use the time to read my favorite blogs and browse my favorite news web sites. Let's say I browse on 30 pages a day and read each long enough for the radio link to go back to idle. In other words, 30 signaling events.
• While I am moving the radio link has to be maintained and handed over to neighboring cells which creates quite a significant amount of signaling, especially with my 'old' N95 that doesn't have fast dormancy and hence the network needs to work more to maintain the established but not really required radio bearer after background push/pull requests.
• Also during quick breaks I try to catch a news bite or two to know what's going on in the world. Lets say that's an extra 10 signaling events per day.
• No instant messaging or other push applications are running in the background but more and more people are doing that these days, too.

In total that's easily 100 signaling events on the PS side per day. Compared to the 15 signaling events on the CS side for voice and SMS, that's quite a difference, not only for the network but also for the mobile, i.e. the impact on the battery charging interval is significant.

Today I've got something positive to say about network coverage in France: While the country has been slower than most other European countries to deploy 3G in areas other than big cities, it seems coverage has much improved in recent years. Over the weekend I was in a remote village near Nantes and experienced great 3G coverage. Quite unexpected! And then on Sunday, a 6 minute call out of a high speed train darting through the countryside at 300 km/h on GSM without a call drop. Very good! Now some more prepaid love for Internet access and I'm a happy customer!

Inspired by this post over at the 3G4G wireless blog on VoLGA and VoLTE architecture differences, I reflected a bit on why it has become a bit silent around LTE voice recently. From a VoLGA point of view, maybe it is because there is little more it can prove until the time real LTE mobile devices (not USB sticks) come to the market.

Back in February 2010, VoLGA was demonstrated at the Mobile World Congress in Barcelona as fully functional, using live network equipment. It's here and it's working but until real devices become available, there is nothing more to be shown that could go beyond it. And with closely related UMA (Unlicensed Mobile Access) stacks used in practice today on Nokia, RIM and Samsung devices for Voice over Wi-Fi, I have little doubt that this final piece can be implemented very quickly. Same thing for VoLTE and CS Fallback, they are there on paper and are waiting for devices they can be implemented on.

But once the solutions can be demonstrated in practice, I expect that the competition between them will accelerate again. It's going to be interesting to see if the simplicity, full functionality from day one, fast call setup times and a relatively simple but hyper-important in-call handover from LTE to GSM / UMTS of VoLGA will trump over other solutions.

Unlicensed Mobile Access, or UMA for short, is basically GSM and GPRS over Wi-Fi. Used by a number of network operators and supported by some phones from Nokia, RIM and others, it's an interesting technology and the basis for VoLGA, a voice over IP solution for LTE that I am quite passionate about. Recently, I stumbled over this website which explains how to configure Wi-Fi Access Points that run the open DD-WRT operating system for the use with UMA phones. Some tips and tricks are given but basically the message is that the Wi-Fi Quality of Service Extensions (WMM) have to be turned on. That also answers one of the questions I had as to whether UMA in practice only runs with access points offered by network operators.  So if you are into the details the link might provide some interesting information for you, too.

Ajit Jaokar over at the Open Gardens blog has started a blog ring to promote a request from the European Internet Foundation (EIF) to answer an online survey of 20 questions to select those to forward to Neelie Kroes, EU commissioner for the digital agenda. So what's it about?:

On May 19th the European Commission adopted its “Digital Agenda” for Europe, proposing some 100 actions – including 31 legislative actions – read here. The European Parliament has also adopted a Report on the Digital Agenda, which you can find here. The EIF wants you to help them choose the questions they ask Vice-President Kroes on the occasion of the 10th Anniversary of EIF in the European Parliament on the evening of July 13th.  The top questions emerging from this survey will be the ones we ask the Commissioner. Video replies will be available on the EIF website, shortly after the event. 

So if you are interested in taking part, have a look here for the questions.

Now I do get around quite a bit and I am always fascinated at the differences that exist of how prepaid wireless Internet access is offered in different countries. Now here are the two most extreme examples I have encountered so far (except for countries in which no prepaid wireless Internet access is offered):

Austria:

Here, you go to a supermarket, buy a prepaid SIM for mobile Internet for 9.98 euros that already includes 512 MB of Internet traffic that is valid for 12 months. No ID, no activation, it works out of the box in 0 seconds. In case you don't have a 3G USB modem yet, you get it together with the SIM + 3GB of data valid for 12 months for less than 50 euros. Details here. Ah yes, and you can choose between many offers and network operators.

Apart from being dead simple for a user, there is also 0 waiting time for the customer and 0 cost as no special stores and no interaction with special sales personnel is required. Remember, you just buy the SIM in the supermarket like a candy bar.

US:

Here, there seems to be only one network operator offering prepaid Internet access for notebooks on GSM/UMTS. You can buy a prepaid SIM but I am not sure if/how one can buy a 3G modem on the spot that works on 850/1900 MHz 3G without a contract. Fortunately I have one anyway 🙂 You get the same amount of data for $50 but only valid for a month. And the wild thing: You need to register the IMEI of the device before the offer is activated. Now that's a first! Not quite as customer friendly as the example above.

I was quite surprised when I heard that the upcoming Nokia N8 would support 5 UMTS bands in a single device. I was skeptical at first but both Wikipedia and Nokia confirm it here and here. In other words, it seems there won't be several hardware versions of the N8 for different parts of the world as was the case for many other devices before. Instead, a single device can be sold and used everywhere. Let's have a look at the bands:

• Band I (UMTS 2100, Europe's main 3G band)
• Band II (UMTS 1900, US band)
• Band IV (UMTS 1700/2100, US band)
• Band V (UMTS 850, US band)
• Band VIII (UMTS 900, Europe and used e.g. in France and Finland in rural areas)

Great stuff which will hopefully find many followers to enable truly global roaming!

A quick one today: Here's a link to a post I stumbled over recently that describes the new features currently discussed for LTE-Advanced in 3GPP Release 10. I haven't yet ventured out too far into the LTE-Advanced land, being quite busy with LTE Release 8 so the article helped me a lot to quickly learn a couple of important things about the different Coordinated Multipoint (COMP) modes and other things in LTE-Advanced. Enjoy!

Speed is not everything in 3G networks as many people in the industry are discovering these days. In addition, improvements now also revolve about reducing the signaling load incurred when a radio bearer is established, modified or released. Another area for improvements is the signaling overhead on the air interface when little data is transferred as it consumes resources and causes battery drain from the mobile's point of view.

In LTE, these things might be less of a worry, as the air interface has been redesigned from scratch and addresses these areas from day one. UMTS, however, did not address such things initially and over recent years a number of enhancements were specified. These are Fast Dormancy (FD, see here), Continuous Packet Connectivity (CPC, see here, here and here) and Cell-PCH (see here), a battery and signaling friendly semi-dormant air interface activity state. I have extensively blogged about these over the last years so for details click on the links and explore. But how do these features come together, are they mutually exclusive or should they be used in combination?

So here is a typical scenario that includes all functionalities above that I think networks and mobile devices could be using in the future once all features are developed and used:

The user of a mobile device starts the web browser and clicks through different pages, quickly at first until the desired piece of information is found, then a bit slower, say one new page every 30 seconds to a minute as subsequent additional information is discovered or read. When the browser is started, the air interface connection is in RRC Idle state, very good for the battery but the time until the first page starts to load is quite long, around 2.5 seconds. Not very good for the user experience. But once the connection is in the RRC Cell-DCH state, getting a page behind a link will be much faster as the radio link is already established. Due to the Continuous Packet Connectivity (CPC) feature, battery drain has been reduced compared to today so the network could keep the connection in the fast Cell-DCH state for much longer than today, say a minute or two.

Once the user is done with web browsing he exits the browser or puts it into the background and there is no further data traffic. The mobile device detects that there is no application in the foreground that exchanges data frequently so it will use the Fast Dormancy Feature specified in 3GPP Release 8 to indicate to the network that it would like to enter a more battery efficient radio state. The network then puts the radio connection into the Cell-PCH RRC state which is both battery efficient and allows the mobile device to resume communication within around 700-800 milliseconds. That is a much improved user experience over the 2.5 seconds from the fully idle state. The state is also good for the network, as a lot less signaling is required once there is renewed activity.

Applications running in the background while the mobile is carried in the pocket have to send keep-alive messages every now and then to keep their connection with a server in the network from timing out. Examples are e-mail push services, instant messengers, etc. These keep-alive intervals could be anywhere from a couple of minutes to half an hour.  As the mobile is in Cell-PCH state, the keep-alive response is received very quickly and the mobile can indicate to the network right after the keep-alive exchange via the fast dormancy mechanism that it wants to go back to a more battery efficient state. No need to linger around in a more battery consuming state as it is unlikely any more data exchange will follow.

For such background message exchanges, the connection could be set to the RRC Cell-DCH state and here, Fast Dormancy has an additional plus for the networks as there are limits to how many users can be kept in Cell-DCH state simultaneously. So in addition to saving battery power it helps the network to remove idle connections from the air interface. Another option is to use the Cell-FACH state for such quick message exchanges, which might be sufficient for the few packets exchanged for the keep-alive, especially if the Forward Access Channel (FACH) uses the fast downlink shared channels, a feature of CPC.

If the user is quickly moving from cell to cell, the downside of the Cell-PCH state is that in each new cell, a Cell Update message has to be sent. This can be countered, as is already done in some networks today, by setting the device into URA-PCH state which only requires a Cell Update message at URA (UMTS Registration Area) boundaries.

It all sounds very complicated but I think it should be manageable and achievable. Except for the new features such as FD Release 8 and CPC, the only other thing required is an intelligent RRC state handling in the mobile device because only there is the knowledge available on what the user and the applications do at the moment. Just invoking fast dormancy when the display's backlight is not on, independent of which applications are running in the background, is too simple. There could be, for example, an application running in the background that streams video from the network and requires data bursts every 10 seconds. Using FD when this happens is quite counter productive. Also, switching fast dormancy off while the backlight is on is also too simplistic because it could just be an MP3 player in the foreground which doesn't interact with the network and hence, fast dormancy can be used for applications running in the background.

In summary, I think all features mentioned in the title of the post will have to be used in the future to run a UMTS network efficiently and to reduce battery consumption as devices with always-on features become more and more common. The required network features are already through the standardization pipe and I am sure mobile device developers are also not sitting on their hands. In other words I am confident that things will be in place once they are needed.

You won't find a lot of iPhone posts on this blog but this one I had to do as I've read that the new iPhone OS (4) in addition to some multitasking support has two interesting features built in that I wanted to have on my devices for years now:

• The first one is a spell checker! Yes, a spell checker, it comes in handy when writing blog posts on the mobile.

• The second one is a list that shows the applications that have used the GPS receiver recently. Great! And by the way: I wonder if the feature allows users to get an idea, when and how often Apple collects location based information in the background and sends it to one of its servers for its own use and for sharing with others (see for example here and here)!? That seems to go even one step further than what's allowed if the user agrees to the Android 'privacy' policy (see here).