Month: June 2010

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).

A couple of days ago I rumbled about some 3GPP specs having become so large that they become almost unmanageable in their word version and creating a PDF document out of them takes ages. One reader left a comment that pretty much fixes the issue for me and I guess his info is of wider interest: ETSI provides PDF versions of the specification documents in short order after they have been published. The 3GPP specification web pages even contain a link to the corresponding ETSI pages. The only thing you need to do to get access to the ETSI version is to register once. A great tip, thanks very much!

To try it yourself, have a look here for example and click on the link on the right next to the version of the document you are interested in.

Apart from much higher speeds, one of the advantages of UMTS networks compared to GSM is that voice and packet switched data can be transferred simultaneously. That comes in quite handy, for example, if you are stuck in a long conference call, as you can still send and receive e-mails and do other things when the conversation touches topics which are not in your area of interest. In GSM this is not possible in most networks.

Many years ago an enhancement was standardized in 3GPP, though, referred to as Dual Transfer Mode (DTM) to catch up with UMTS. Nokia and other manufacturers have supported this extension for years but I have never seen a network that would actually support it. Then, earlier this year I read in a support forum that an operator in the UK has activated DTM. Needless to say I was very much looking forward to my next trip to the UK to try it out.

It has taken half a year but I finally made it to London and gave it a try. Very nice it works as designed. While in a voice call, I get data rates of around 120-140 kbit/s which is  only slightly less (one EDGE timeslot I presume) compared to data transfer rates while no voice call was ongoing. Well, done, I hope it's a growing trend!

Ash clouds, broken cockpit windows and other things sometimes make you stick around an airport for a bit longer than originally anticipated. Recently, I had to wait for a flight for 8 hours and as you can imagine, I was a bit less than not amused. But the bright side of it was that with 3G and Wi-Fi connectivity I could put the 8 hours into good use, connect to the company network and get a day's work done. If not I would have wondered aimlessly through the halls, maybe tried to read a book and probably have been very upset by the whole thing. So a little advice to airlines: Instead of just giving out vouchers for food, consider giving out Wi-Fi vouchers as well to waiting passengers. I guess some would even prefer that.

One of the things currently hotly debated in the industry is how to fix a current shortcoming of 3G UMTS networks, switches between different mobile device activity states on the air interface. The topic has many facets but it's possible to put the pieces together because 3GPP is pretty open about the standardization process as all documents are out in the
open and available to everyone. That doesn't only include the
specification documents but also all change requests and also discussion papers. This significantly helps to understand the issues different parties have with a topic. For this post I am going to draw
heavily on them while also explaining my own opinion.

So what's this all about?

Actually, it's about two things: The UMTS air interface knows several activity states that are known as Cell-DCH, Cell-FACH, Cell/URA-PCH and Idle. When transferring data, the mobile is usually in Cell-DCH state and uses high speed channels to transmit and receive data (HSDPA, HSUPA). That's great but even if no data is sent and received, e.g. while the user reads a web page, it still requires a lot of energy on the mobile device's side to keep the connection going. On the network side, it's also a waste of resources to leave a mobile in Cell-DCH state when it is not transmitting data as there are only so many mobiles that can be assigned a high speed channel at a time. So both sides have an interest to move a connection to another state while it is not needed. In most networks today, a connection is moved to Cell-FACH state, which requires less energy and supports more users. Here, however, data throughput is very low and the amount of energy required on the mobile's side is still significant. Consequently, if there is an even longer inactivity time, e.g. 30 seconds, the network then puts the connection in Idle state in which the physical connection is removed while the IP address is kept.

So, what's wrong with that?

From the mobile device side this behavior can be very inefficient as a lot of energy is wasted before the Idle state is reached, especially when only background applications such as e-mail clients and instant messengers every now and then contact a server to remain reachable. As a consequence a number of of manufacturers have come up with a scheme that is referred to as Fast Dormancy. As described in this document, a mobile uses a "Signaling Channel Release Indication" message to trigger a release of the air interface connection when it thinks it is no longer necessary. So instead of waiting for the connection to be put into Cell-FACH and finally into idle, it can trigger a release to idle immediately. This significantly increases battery lifetime and if it is done in a reasonable way, it has no impact on today's networks as they would put the connection into Idle anyway, just a bit later. If for some reason, however, this functionality is improperly used, the air interface starts to oscillate between the states which is very inefficient for both the mobile, as a lot of power is required, and also for the network, because a lot of signaling is required between the Radio Network Controller, the base station and the mobile device to switch between the states.

The problem with the Idle State

While the Idle state is ideal for saving power on the mobile device's side, there is a big downside to using this state: When there is renewed activity it takes around 2.5 seconds before data can be exchanged again, something that is quite noticeable to the user. A solution to this is not putting the mobile device in Idle state but rather in the so called Cell- or URA-PCH state. From a mobile point of view, the Cell-/URA-PCH state is quite similar to Cell-FACH with the major difference being that the downlink does not have to be observed continuously. Only the paging channel must be checked every now and then to make sure incoming IP packets, phone calls or SMS messages can be received. In other words, the energy required to remain in this state is similar to the energy required for maintaining the Idle state but the signaling connection remains in place. When the mobile wants to transmit data again, it can immediately go to Cell-FACH state as there is no need to establish a signaling connection, perform an authentication procedure, enable ciphering, etc. This significantly reduces the time it takes before the first packet can be sent as described here. For the network, the advantage is that much less signaling is required for returning the device to a full Cell-DCH high speed state compared to doing the same from Idle.

Fast Dormancy and Cell-/URA-PCH

The issue with todays Fast Dormancy described above is that in case a network uses Cell-/URA-PCH, these states are not reached as the mobile triggers a complete release of the signalling connection. Hence, while the mobile device saves the maximum amount of energy, the network can not take advantage of the signaling reduction of the Cell-/URA-PCH states. Also, the mobile device can't benefit from the fast return to service times described above. From a mobile point of view, the current fast dormancy behavior being applied when there are only background applications is still preferable to waiting for the network sending it to Cell-/URA-PCH state as a lot of energy is wasted waiting for the network to make the decision. It should be noted at this point that the network is not slow in making the decision, it's rather intentional to ensure a good user experience to only have a user plane latency due to the state switching when absolutely necessary.

The Fix For Everything

So while today's fast dormancy implementations work well and do not have a negative impact on networks as most do not (yet) use the Cell-/URA-PCH states, things are o.k. for the moment. However, if network operators in the future decide to use the Cell-/URA-PCH states, the current fast dormancy implementations will become counter productive. As a result, a new mechanism has been specified in 3GPP TS 25.331 Release 8.10.0 (see chapter 8.1.14). Instead of just releasing the signaling connection when it desires the mobile has to wait for the expiration of a network configured timer (T323). Once the timer expires, the mobile can send a signaling connection release indication message with a new parameter that indicates "UE requested PS data session end". At this point the network can then decide to do nothing, to release the mobile to Idle or to put the connection into Cell-/URA-PCH state.

Network operators probably like this new mechanism as control over the air interface is returned to the network. Mobile devices also benefit from it as instead of going to Idle, the network can also put them to Cell-/URA-PCH state and hence, the latency when returning to a fully active state is much shorter than from the Idle state.

It's even possible to implement both fast dormancy approaches in a mobile. The availability of a value for timer T323 in the system broadcast of a cell can be used as a criterion to decide whether to use today's fast dormancy in case T323 is not present in the system broadcast or to use the new mechanism in case it is found. An elegant and backwards compatible solution with benefits for everyone.

Summary

From my point of view today's fast dormancy implementation does not harm networks as most have not activated Cell-/URA-PCH states yet. For the future, the new 3GPP Release 8 feature further improves on today's functionality and is backwards compatible. A win-win situation for everyone involved.

The Paris metro remains an interesting research location for me as especially during rush hour you can easily experience what congestion does to a network. Even with Opera Mini it's difficult to use the network at such times as you can almost see individual bits trickling in. Anyway, so I was wondering for a long time just how many cells they have in the metro to get an idea of the effort invested and the capacity available.

Recently I had the time and opportunity to dig a bit deeper. One line number 12 I've been looking, each metro station is covered by its own cell. By extending the coverage into the tunnels, handovers for voice calls and uninterrupted web browsing works most of the time. In other words, once cell has to absorb the load generated by all people currently waiting for a metro plus the traffic generated by the people in the metro trains currently in the stations or the tunnels.

That's an important first indication of the capacity deployed but a second parameter to come to a conclusion is more difficult to obtain: The number of carriers deployed. Unfortunately, that can't be seen with publicly available methods such as using AT commands that give you the current cell-id whenever it changes. So that part remains a mystery for the moment.

But capacity seems to be sufficient for voice calls, as all call attempts I made on the trip resulted in a connection. So no blocking here. The GPRS / EDGE side of the network is another story though. While speeds are good during non rush-hour times, the PS side is totally overloaded when people go and come from work. So either there are not enough timeslots available or some of them are taken for voice calls. Again, difficult to tell.

But one thing is good to know: With one base station per metro station, it is much easier for network operators to increase capacity if they wanted to compared to a situation in which a single cell was used for much longer parts of the underground network. But please don't bother adding a GSM TRX or two, just add 3G to the mix as other cities have already done to fix the issue for good.

I am just sitting in a café enjoying a late breakfast working on some stuff on my netbook. Instead of being connected over 3G I use the local Wi-Fi hotspot and a VPN for security. Not that I don't like using the 3G macro network but this way I don't have to plug in a 3G USB stick. But then, this comes at the expense of slower speeds as the Wi-Fi hotspot seems to be connected to a slow ADSL line with 'only' 2 MBit/s in the downlink direction and a couple of hundred kilobits in the uplink.

I just noticed this when sending an e-mail with a large file attachment as it took a couple of minutes for it to trickle through the line. I was tempted to stop the data transfer and use the 3G stick instead. With HSUPA and uplink speeds of 1.5 MBit/s it would have been much faster. But then, too much work to reorganize (…), so I just put the transmission into the background and continued working on other stuff in the meantime.

There we go, now hotspots aren't necessarily always faster anymore compared to the macro network.

Back in December 2007 I wrote a post on the term 'dumb pipe' that was starting to make the round and spreading negative emotions around the topic that in the Internet world, networks are transporting data while Internet based companies are actually getting the service revenue. I can understand where this twist came from but suggested that there is another way to look at it:

In an article by Chris Anderson, he pointed out that fact that most services on the net are pretty specialized and are hence on 'a long tail' and don't really make very much money at all for the service provider. However, for those enabling the services, i.e. the networks, it very well generates money. When applied to network operators, long tail services provide the incentive in the first place for people to go online and spend money for connectivity. At the time the term 'long tail enabler' started to emerge in my mind and I have used it ever since when somebody mentioned the 'dumb pipe' to offer an alternative way to look at it.

Obviously, the term 'long tail enabler' is a bit clunky to explain to someone who's not heard of the 'long tail' concept before. Now Dean Bubley over at Disruptive Wireless has come up with the term 'happy pipe' and part of what he means with this goes in my direction. I very much like the term as it contrasts a wording with a very negative spin with a wording that has a very positive spin.