Category: Uncategorized

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.

I've rumbled before about the size of the 3GPP 3G Radio Resource Control Specification TS 25.331 here when I noticed the significant size difference to the much more lightweight brother specification for LTE. You can feel the whole weight of it when you try to open it and search for something specific. Without a mainframe computer it's impossible to browse it efficiently anymore and converting it to PDF to make it a bit more manageable is a night time task while you sleep. So hey, guys over there in RAN, how about splitting this document up in several parts!? It's been done before for other specs, ask the RAN4 people and have a look at the split test specs documents 🙂

I have just arrived in one of the few cities in this part of the world in which the metro (underground, tube, whatever you call it) is not covered by mobile networks. It's a sad state but maybe the mobile gaming industry is rejoicing as I noticed a lot of people this time using their mobile device, which has become utterly useless once they stepped into the underground for one of the few things that still work without the network: Offline gaming. But one could also turn the stick around and ask: As more people go online on their mobile devices, will mobile gaming revenues decrease due to people preferring to do things online rather than playing a game while commuting?

It's been a while since I last wrote a post on Bluetooth because the latest and greatest version that has been in use now for a number of years is still 2.1. Last year, however, the Bluetooth SIG finalized version 3 of the standard which includes the use of a Wi-Fi radio as a high speed option to transfer data. And just a couple of weeks ago, the Bluetooth SIG finalized version 4 of the standard for ultra low energy data transmission.

So are you aware of any Bluetooth v3 devices that will appear on the market anytime soon? I can imagine a couple of applications such as transmitting pictures quickly from the mobile phone to a Bluetooth / Wi-Fi enabled photo printer or to a PC but I haven't seen any announcements yet!?

And what about Bluetooth v4? What's the likelihood of devices using the low energy option in the next couple of years and which applications will be first?

I'll keep looking!

P.S.: For those with an appetite for the details, you can download all versions of the BT core specifications here.